Re: [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System

[Chris Stewart via bitcoin-dev]

>In traditional finance, front-running is defined as "entering into an
equity trade, options or future contracts with advance knowledge of a block
transaction that will influence the price of the underlying security to
capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running
could be a board on the discovery of a batch of market offers increasing
liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a
HTLC across a Lightning payment path to enter into the trade, before
publishing the offer on its board.

To summarize, assume we have Mary the Maker, Terry the Taker, and Bob the
bulletin board operator

1. Mary the Maker publishes a limit order to buy a derivative
2. Bob the bulletin board operator has the option to execute against Mary's
order
3. If Bob doesn't want to execute against the order, he relays the order to
Terry the Taker (and other subscribers to Bob's market)
4. Terry has the option to execute a trade against Mary's limit order
5. If Terry decides not to execute, Mary's order sits on the bulletin board.

I personally don't think this is that big of a concern, if Bob can collect
outsized profits from his trusted position as the bulletin board operator,
Terry will eventually move to other markets because Bob is only relaying
what Bob perceives to be unprofitable orders.

>From the perspective of Mary, she is happy. Her order got executed at the
price she specified. Terry is the one that loses here. This model ends up
looking much more like a brokerage rather than an exchange market
structure. Terry should open up his own brokerage (bulletin board) and
compete on quoting prices with Bob.

Bob and Terry can then be compared on metrics like execution quality
, which then
draws more market activity since they are providing better prices.

>Somehow mass front-running on the board is a "champagne" issue I'll be
happy to have.

This. Frontrunning is a good problem to have, that means your market has
active participants and liquidity. Finding what products people are
interested in trading, and giving them a good user experience is more
important. Everything else will fall in line after that.


On Mon, May 1, 2023 at 1:06 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> One of the most relevant feedback I received on the paper publication was the 
> lack of underscoring front-running resistance as a fundamental property 
> wished for a peer-to-peer marketplace.
>
> It is expected the level of front-running resistance aimed by the market 
> participants to be heavily functioned by the types of trades considered: fiat 
> currencies, real goods, services. For some classes of goods, e.g commodities 
> one cannot expect the same level of item liquidity due to cycle of production 
> and exogenous factors like weather. Some types of trades marketplaces might 
> be exposed to far less front-running risks and rather would have to deal with 
> accurate risk modelling of the underlying goods. E.g attest there is a 
> decentralized identifier or any other linkage proof of the physical good 
> existence staying valid for the duration of offer lifetime. Offers conditions 
> themselves might be far more verbose and precise special Bitcoin Script paths 
> to morph the shipment risks.
>
> On the other hand, the types of trades like fiat currencies or bitcoin 
> financial contracts (e.g discreet log contracts or submarine swaps), 
> front-running risk by the bulletin board sounds a qualified concern. In 
> traditional finance, front-running is defined as "entering into an equity 
> trade, options or future contracts with advance knowledge of a block 
> transaction that will influence the price of the underlying security to 
> capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running 
> could be a board on the discovery of a batch of market offers increasing 
> liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a HTLC 
> across a Lightning payment path to enter into the trade, before publishing 
> the offer on its board.
>
> I think you have at least two security paradigms to mitigate front-running 
> happening peer-to-peer marketplace. The first one is to duplicate the 
> announcement of the offers to a number of concurrent board operated by 
> independent identities and in parallel monitor the latency. Latency anomalies 
> should be spotted on by watchtower-like infrastructure at the service of 
> makers/takers and in case of repeated anomalies a maker should disqualify the 
> misbehaving board from future announcements. As all statistical mitigation it 
> is not perfect and open the way to some margin of exploitation by the boards, 
> as the watchtower monitoring frequency can be guessed. Additionally, this 
> latency monitoring paradigm sounds to be valid under the assumption that at 
> least one board is "honest" and board might have a 

[bitcoin-dev] Release of bitcoin-s 1.9.1

[Chris Stewart via bitcoin-dev]

Today we are executed to release 1.9.1 of bitcoin-s. Bitcoin-s is a set of
bitcoin libraries written in Scala. We adhere to the Discreet Log Contract
specification . For more
information please see bitcoin-s.org or read the release notes for the
1.9.1 release.

- https://github.com/discreetlogcontracts/dlcspecs
- bitcoin-s.org
- https://github.com/bitcoin-s/bitcoin-s/releases/tag/1.9.1

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

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart via bitcoin-dev]

FWIW, the initial use case that I hinted at in the OP is for lightning.

The problem this company has is they offer an inbound liquidity service,
but it is common after a user purchases liquidity, the channel goes unused.

This is bad for the company as their liquidity is tied up in unproductive
channels. The idea was to implement a monthly service fee that requires the
user to pay a fixed amount if the channel isn’t being used. This
compensates the company for the case where their liquidity is NOT being
used. With standard lightning fees, you only get paid when liquidity is
used. You don’t get paid when it is NOT being used. If you are offering
liquidity as a service this is bad.

The user purchasing liquidity can make the choice to pay the liquidity fee,
or not to pay it. In the case where a user does not pay the fee, the
company can take this as a signal that they are no longer interested in the
service. That way they can put their liquidity to use somewhere else that
is more productive for the rest of the network.

So it’s sort of a recurring payment for liquidity as a service, at least
that is how I’m thinking about it currently.

On Sun, Mar 6, 2022 at 2:11 PM ZmnSCPxj  wrote:

> Good morning Chris,
>
> > >On the other hand, the above, where the oracle determines *when* the
> fund can be spent, can also be implemented by a simple 2-of-3, and called
> an "escrow".
> >
> > I think something that is underappreciated by protocol developers is the
> fact that multisig requires interactiveness at settlement time. The
> multisig escrow provider needs to know the exact details about the bitcoin
> transaction and needs to issue a signature (gotta sign the outpoints, the
> fee, the payout addresses etc).
> >
> > With PTLCs that isn't the case, and thus gives a UX improvement for
> Alice & Bob that are using the escrow provider. The oracle (or escrow) just
> issues attestations. Bob or Alice take those attestations and complete the
> adaptor signature. Instead of a bi-directional communication requirement
> (the oracle working with Bob or Alice to build the bitcoin tx) at
> settlement time there is only unidirectional communication required.
> Non-interactive settlement is one of the big selling points of DLC style
> applications IMO.
> >
> > One of the unfortunate things about LN is the interactiveness
> requirements are very high, which makes developing applications hard
> (especially mobile applications). I don't think this solves lightning's
> problems, but it is a worthy goal to reduce interactiveness requirements
> with new bitcoin applications to give better UX.
>
> Good point.
>
> I should note that 2-of-3 contracts are *not* transportable over LN, but
> PTLCs *are* transportable.
> So the idea still has merit for LN, as a replacement for 2-fo-3 escrows.
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart via bitcoin-dev]

>On the other hand, the above, where the oracle determines *when* the fund
can be spent, can also be implemented by a simple 2-of-3, and called an
"escrow".

I think something that is underappreciated by protocol developers is the
fact that multisig requires interactiveness at settlement time. The
multisig escrow provider needs to know the exact details about the bitcoin
transaction and needs to issue a signature (gotta sign the outpoints, the
fee, the payout addresses etc).

With PTLCs that isn't the case, and thus gives a UX improvement for Alice &
Bob that are using the escrow provider. The oracle (or escrow) just issues
attestations. Bob or Alice take those attestations and complete the adaptor
signature. Instead of a bi-directional communication requirement (the
oracle working with Bob or Alice to build the bitcoin tx) at settlement
time there is only unidirectional communication required. Non-interactive
settlement is one of the big selling points of DLC style applications IMO.

One of the unfortunate things about LN is the interactiveness requirements
are very high, which makes developing applications hard (especially mobile
applications). I don't think this solves lightning's problems, but it is a
worthy goal to reduce interactiveness requirements with new bitcoin
applications to give better UX.

-Chris

On Sat, Mar 5, 2022 at 4:57 PM ZmnSCPxj  wrote:

> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-approved credit
> from a bitcoin wallet. The line can be drawn down with oracle attestations.
> You can mix in locktimes on these pre-approved lines of credit if you would
> like to rate limit, or ignore rate limiting and allow the full utxo to be
> spent by the borrower. It really is contextual to the use case IMO.
>
> Ah, that seems more useful.
>
> Here is an example application that might benefit from this scheme:
>
> I am commissioning some work from some unbranded workperson.
> I do not know how long the work will take, and I do not trust the
> workperson to accurately tell me how complete the work is.
> However, both I and the workperson trust a branded third party (the
> oracle) who can judge the work for itself and determine if it is complete
> or not.
> So I create a transaction whose signature can be completed only if the
> oracle releases a proper scalar and hand it over to the workperson.
> Then the workperson performs the work, then asks the oracle to judge if
> the work has been completed, and if so, the work can be compensated.
>
> On the other hand, the above, where the oracle determines *when* the fund
> can be spent, can also be implemented by a simple 2-of-3, and called an
> "escrow".
> After all, the oracle attestation can be a partial signature as well, not
> just a scalar.
> Is there a better application for this scheme?
>
> I suppose if the oracle attestation is intended to be shared among
> multiple such transactions?
> There may be multiple PTLCs, that are triggered by a single oracle?
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart via bitcoin-dev]

Hey ZmnSCPxj,

I thought about this for a few days and I think you are right. In the case
of recurring payments this is identical to nLocktime. When doing recurring
payments with this scheme, you probably want to rate limit subsequent UTXOs
_with_ nlocktimes to make sure a malicious Netflix can't withdraw 12 month
so of subscriptions by attesting with their oracle 12 times.

I think this proposal describes arbitrary lines of pre-approved credit from
a bitcoin wallet. The line can be drawn down with oracle attestations. You
can mix in locktimes on these pre-approved lines of credit if you would
like to rate limit, or ignore rate limiting and allow the full utxo to be
spent by the borrower. It really is contextual to the use case IMO.

-Chris

On Fri, Mar 4, 2022 at 2:22 AM ZmnSCPxj  wrote:

>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over just handing over `nLockTime`d transactions?
>
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart via bitcoin-dev]

DLCs are typically thought to be used for betting. Alice & Bob want to
speculate on an event, and have bitcoin payouts rewarded to them if they
bet correctly. The oracle determines what event occurred and produces
attestations representing that outcome.

Recently I had a conversation with a friend about implementing recurring
subscriptions with Discreet Log Contracts. At a high level, you should
think about this working like ACH. If you are purchasing a subscription
from Netflix, they will deduct $20 from your bank account every month. To
do this, you give them your credit card information.

You can do this with Discreet Log Contracts. It requires a slightly
modified DLC setup. Netflix would create an oracle representing a monthly
subscription. They require that users setup DLCs to them that will be
executed at the end of the month. Alice, a subscriber to Netflix, creates a
unilaterally funded DLC to Netflix. She creates adaptor signatures for her
payment and sends them to Netflix.

No bitcoin transaction is required to create this subscription since the
DLC is unilaterally funded. Alice can “cancel” the subscription at any time
by spending from the utxo she is using to fund the DLC.

At the end of the month, Netflix attests that it is time to charge Alice
for her subscription. Netflix takes its own attestation and decrypts
Alice’s adaptor signature to get her signature to send funds to Netflix.
Netflix publishes the settlement transaction for the DLC which pays Netflix
it’s subscription fee for the next month. Netflix also publishes a new
announcement for next month so that Alice can create a new DLC subscription.

Netflix needs to give Alice a bitcoin address to pay to.

The information Alice is required to send Netflix is


   1.

   Her utxo used to fund the DLC
   2.

   Her adaptor signature representing her monthly subscription to netflix.


Netflix must verify the adaptor signatures are correct and the utxo exists.

Why is this useful?

It's very convenient for a user to give access to withdraw a certain amount
of money from a bank account at a given time in the future. This is how
recurring payments work in tradfi. This brings the same principle to
bitcoin payments.

DLCs also give you the power to specify how much the service can withdraw.
For instance, with Netflix, they shouldn’t have the ability to withdraw
thousands of dollars worth of bitcoin. The monthly service fee is $20. With
DLCs, you can cryptographically enforce that they will only receive $20.
They cannot withdraw more or less money than they are authorized to.

There may be concerns about Netflix being both the oracle and the entity
receiving a monthly payment. I would argue this is mitigated by the fact
that the service provider could steal at most one months worth of service
fees for users of the subscription. After users get scammed once, they will
cancel their future subscription and distrust the service. The key feature
is the amount of money in the subscription is predetermined, thus the
oracle cannot withdraw excess funds if they are evil.

### QA

Does the DLC use a 2 of 2 multisig between Netflix and Alice?

No, the DLC is unilaterally funded by Alice. This allows her to create the
subscription without an onchain transaction, and also allows her to cancel
the subscription at any time. She cancels the subscription by double
spending the utxo.

Can Netflix steal all the money in the funding output?

No, Alice’s adaptor signatures allow Netflix to withdraw a specific amount
of bitcoin. The change is sent back to an address Alice controls. Both of
these outputs are protected by the adaptor signature.

Is there a perverse incentive for Netflix to be the oracle and receive the
subscription?

The most Netflix can steal in this setup is one months worth of
subscription fees across the entire customer base. In this setup, Alice is
accepting that risk for the convenience of auto withdrawals from her
bitcoin wallet. Remember, Alice can cancel the subscription at any time she
wants by spending from the funding utxo.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin-s 1.8 released with DLCs negotiation via Tor

[Chris Stewart via bitcoin-dev]

Hi all,

We released 1.8 today of bitcoin-s. This includes support for opening DLCs
over tor. This makes the UX much simpler to enter into a DLC with your
counterparty.

As part of this release, we wrote two detailed examples of entering into

1. A wallet election example

2. A wallet price example


These are meant to complement the existing oracle examples we have

1. An election oracle example

2. A price oracle example


*This is alpha software, please do not use it for large amounts of money.*

You need a github account to access the downloads, the artifacts are at the
very bottom of the release notes.

https://github.com/bitcoin-s/bitcoin-s/releases/tag/1.8.0

You can find a demonstration video for using the wallet to enter into a DLC
over tor here:

https://www.youtube.com/watch?v=oR0I0aHxNMM

You can find the dlc spec here:

https://github.com/discreetlogcontracts/dlcspecs

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

[bitcoin-dev] Bitcoin-s v0.4.0 release

[Chris Stewart via bitcoin-dev]

Hi all,

We just released v0.4.0 of bitcoin-s.

Major features include

- Wallet overhaul to support all common script types
- Sqlite and postgres database support for all projects
- Improved robustness of the neutrino node
- BIP340 Schnorr Signatures implemented in Java (Bouncy Castle)
- Wallet rescans with block filters
- Testkit contains all new features so you can re-use our code to test
your bitcoin applications

See the release notes here:

https://github.com/bitcoin-s/bitcoin-s/releases/tag/v0.4.0

or our 'Getting Started' section on our website

https://bitcoin-s.org/docs/next/getting-started

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

[bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification

[Chris Stewart via bitcoin-dev]

Hi all,

Suredbits and Crypto Garage have begun to work on a specification for
using discreet
log contracts  in a safe, private and
interoperable way. We are writing to the mailing list to inform and solicit
feedback for the protocol specification so that we can -- as a community --
agree on a common standard to use Bitcoin oracles.

Our goal is to end up with a set of documents like the BIPs (Bitcoin
Improvement Proposals) and BOLTs (Basis of Lightning Technology) so that
others that wish to use the technology can easily write software to
integrate into the protocol.

A secondary goal of ours is to remain compatible with standards used by
other bitcoin related protocols (like Lightning) so that every future
bitcoin related protocol can reach for a “toolbox” of agreed standards for
things like funding transactions and closing transactions. We want to avoid
reinventing the wheel where possible and allow for library developers to
re-use software to hook into many bitcoin related protocols.

You can find the specification repository here:

https://github.com/discreetlogcontracts/dlcspecs/

For more information on DLCs:

[1] - https://adiabat.github.io/dlc.pdf

[2] - https://cryptogarage.co.jp/p2pd/

[3] -
https://suredbits.com/discreet-log-contracts-part-1-what-is-a-discreet-log-contract/

[4] -
https://blockstream.com/2019/04/19/en-transacting-bitcoin-based-p2p-derivatives/

[5] - https://dci.mit.edu/smart-contracts

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

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

[Chris Stewart via bitcoin-dev]

> I don't find too compelling the potential problem of a 'bad wallet
designer', whether lazy or dogmatic, misusing noinput. I think there are
simpler ways to cut corners and there will always be plenty of good wallet
options people can choose.

In my original post, the business that I am talking about don't use "off
the shelf" wallet options. It isn't a "let's switch from wallet A to wallet
B" kind of situation. Usually this involves design from ground up with
security considerations that businesses of scale need to consider (signing
procedures and key handling being the most important!).

>Because scripts signed with no_input signatures are only really exchanged
and used for off-chain negotiations, very few should ever appear on chain.
Those that do should represent non-cooperative situations that involve
signing parties who know not to reuse or share scripts with these public
keys again. No third party has any reason to spend value to a
multisignature script they don't control, whether or not a no_input
signature exists for it.

Just because some one is your friend today, doesn't mean they aren't
necessarily your adversary tomorrow. I don't think a signature being
onchain really matters, as you have to give it to your counterparty
regardless. How do you know your counterparty won't replay that
SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on
"good-will" for their counter parties for security.

>As I mentioned before, I don't think the lazy wallet designer advantage is
enough to justify the downsides of chaperone signatures. One additional
downside is the additional code complexity required to flag whether or not
a chaperone output is included. By comparison, the code changes for
creating a no_input digest that skips the prevout and prevscript parts of a
tx is much less intrusive and easier to maintain.

>I want to second this. The most expensive part of wallet design is
engineering time. Writing code that uses a new sighash or a custom
script with a OP_CODE is a very large barrier to use. How many wallets
support multisig or RBF? How much BTC has been stolen over the entire
history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE
vs ECDSA nonce reuse

I actually think lazy wallet designer is a really compelling reason to fix
footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy
wallet design. Now we have non-malleable transactions in the form of segwit
(yay!) that prevent this exploit. We can wish that the Mt Gox wallet
designers were more aware of bitcoin protocol vulnerabilities, but at the
end of the day the best thing to do was offering an alternative that
circumvents the vulnerability all together.

Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have
virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly
every transaction. The feature -- ECDSA in this case -- was managed to be
done wrong by wallet developers causing fund loss. Unfortunately we can't
protect against this type of bug in the protocol.

If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it
doesn't matter if they are secure or insecure. I'm hopefully that offchain
protocols will achieve wide adoption, and I would hate to see money lost
because of this. Even though they aren't used, in my OP I do advocate for
fixing these.

> understand the desire to be conservative with protocol changes that could
be misused. However, with just taproot and taproot public key types the
anyprevout functionality is already very opt-in and not something that
might accidentally get used. Belt-and-suspender protections like chaperone
signatures and tagged outputs have their own impacts on code complexity,
on-chain transaction sizes and transaction anonymity that also must be
considered.

I'm making the assumption that the business has decided to use this
feature, and in my OP I talk about the engineering decisions that will have
to be made support this. I'm hoping the "lazy wallet designers" -- or
perhaps people that don't follow bitcoin protocol development as rabidly as
us :-) -- can see that nuance.

-Chris



On Tue, Oct 1, 2019 at 8:36 AM Richard Myers  wrote:

> Thanks Christian for pulling together this concise summary.
>
> 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout.
>>
>
> I certainly support the unification and adoption of the sighash_noinput
> and anyprevoutput* proposals to enable eltoo, but also to make possible
> better off-chain protocol designs generally.
>
> Among the various advantages previously discussed, the particular use case
> benefits from eltoo I want to take advantage of is less interactive payment
> channel negotiation.
>
> In talking with people about eltoo this summer, I found most people
> generally support adding this as an option to Lightning. The only general
> concern I heard, if any,  was the vague idea that rebindable transactions
> could be somehow misused or 

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

[Chris Stewart via bitcoin-dev]

I do have some concerns about SIGHASH_NOINPUT, mainly that it does
introduce another footgun into the bitcoin protocol with address reuse.
It's common practice for bitcoin businesses to re-use addresses. Many
exchanges [1] reuse addresses for cold storage with very large sums of
money that is stored in these addreses.

It is my understanding with this part of BIP118

>Using NOINPUT the input containing the signature no longer references a
specific output. Any participant can take a transaction and rewrite it by
changing the hash reference to the previous output, without invalidating
the signatures. This allows transactions to be bound to any output that
matches the value committed to in the witness and whose witnessProgram,
combined with the spending transaction's witness returns true.

if an exchange were to once produce a digital signature from that cold
storage address with a SIGHASH_NOINPUT signature, that signature can be
replayed again and again on the blockchain until their wallet is drained.
This might be able to mitigated since the signatures commit to outputs,
which may be small in value for the transaction that SIGHASH_NOINPUT was
used. This means that an exchange could move coins from the address with a
larger transaction that spends money to a new output (and presumably pays a
higher fee than the smaller transactions).

### Why does this matter?

It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
protocols like Lightning. This gives us the building blocks for enforcing
specific offchain states to end up onchain [2].

Since this tool is useful, we can presume that it will be integrated into
the signing path of large economic entities in bitcoin -- namely exchanges.
Many exchanges have specific signing procedures for transactions that are
leaving an exchange that is custom software. Now -- presuming wide adoption
of off chain protocols -- they will need to have a _second unique signing
path that uses SIGHASH_NOINPUT_.

It is imperative that this second signing path -- which uses
SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
controls an exchanges onchain funds. If this were to happen, fund lost
could occur if the exchange is reusing address, which seems to be common
practice.

This is stated here in BIP118:

>This also means that particular care has to be taken in order to avoid
unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
used, unless it is explicitly needed for the application, e.g., it MUST NOT
be a default signing flag in a wallet implementation. Rebinding is only
possible when the outputs the transaction may bind to all use the same
public keys. Any public key that is used in a NOINPUT signature MUST only
be used for outputs that the input may bind to, and they MUST NOT be used
for transactions that the input may not bind to. For example an application
SHOULD generate a new key-pair for the application instance using NOINPUT
signatures and MUST NOT reuse them afterwards.

This means we need to encourage onchain hot wallet signing procedures to be
kept separate from offchain hot wallet signing procedures, which introduces
more complexity for key management (two keychains).

One (of the few) upsides of the current Lightning penalty mechanism is that
fund loss can be contained to balance of the channel. You cannot do
something in the current protocol that will effect your funds outside of
that channel. With SIGHASH_NOINPUT, that property changes.

### A side note
In general, i think we should start disallowing uses of the SIGHASH
protocols that have unexpected behavior. The classic example of this is
SIGHASH_SINGLE [3]. I get uneasy about adding more footguns to the
protocol, which with current network behavior (address re-use)
SIGHASH_NOINPUT would be a big one.


[1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
[2] -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
[3] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html

On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> With the recently renewed interest in eltoo, a proof-of-concept
> implementation
> [1], and the discussions regarding clean abstractions for off-chain
> protocols
> [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
> (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
>
> (sorry for the long e-mail. I wanted to give enough context and describe
> the
> various tradeoffs so people don't have to stitch them together from
> memory. If
> you're impatient there are a couple of open questions at the bottom)
>
> Both proposals are ways to allow rebinding of transactions to new outputs,
> by
> adding a sighash flag that excludes the output when signing. This allows
> the
> transaction to be bound to any output, without needing a new signature, as
> long as output script and input 

Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE

[Chris Stewart via bitcoin-dev]

Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
else on the dev list can enlighten me, but is there a current use case for
SIGHASH_NONE that would suffer from it being non standard?

-Chris


On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE
> without matched output:
>
> https://github.com/bitcoin/bitcoin/pull/13360
>
> Signature of this form is insecure, as it commits to no output while users
> might think it commits to one. It is even worse in non-segwit scripts,
> which is effectively SIGHASH_NOINPUT|SIGHASH_NONE, so any UTXO of the same
> key could be stolen. (It’s restricted to only one UTXO in segwit, but it’s
> still like a SIGHASH_NONE.)
>
> This is one of the earliest unintended consensus behavior. Since these
> signatures are inherently unsafe, I think it does no harm to disable this
> unintended “feature” with a softfork. But since these signatures are
> currently allowed, the first step is to make them non-standard.
> ___
> 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] Two Drivechain BIPs

[Chris Stewart via bitcoin-dev]

>As far as I can tell there is no opportunity cost to casting a malicious
vote, no repercussions, and no collective action barrier that needs to be
overcome.

There is another interesting analysis on BMM and drivechains from /u/almkglor
on reddit
.
I'm going to share here for visibility.

The problem with drivechains and blind merged mining is the disconnect
> between voting and "blind" merge mining. With BMM, a miner can do:
>
>1. Not accept BMM, not vote.
>2. Not accept BMM, operate their own sidechain node, mine sidecoin,
>and vote correctly.
>3. Not accept BMM, always upvote (i.e. allow theft).
>4. Not accept BMM, always downvote (i.e. strangle).
>5. Accept BMM, not vote.
>6. Accept BMM, operate their own sidechain node, and vote correctly.
>(not mine sidecoin directly: they get paid in maincoin by sidecoin-only
>miners).
>7. Accept BMM, always upvote (i.e. allow theft).
>8. Accept BMM, always downvote (i.e. strangle).
>
> 3 and 7 will mean that non-verifying miners will be (inadvertently)
> complicit in theft. Drivechains have 1008-block cycles ostensibly to
> protect against theft, so that someone can "raise the alarm" and tell
> miners to downvote a particular theft withdrawal, but that sounds too much
> like centralized collusion to me.
>
> Strategy 8 will dominate over strategy 6, since the miner does not have to
> run a sidechain node (reduced cost) while still earning the same as
> strategy 6.
>
> Strategies 5->8 are all strictly superior to 1->4, so BMM does not really
> change anything: strategy 8 (equivalent to strategy 4 if BMM is not
> implemented) will still choke strategy 6 (equivalent to strategy 2 if BMM
> is not implemented)
>
> It seems Drivechain's security model is: miners always upvote by default.
> If a theft withdrawal is done on the mainchain, some sidechain nodes call
> up their miner friends (which makes me worry about miner centralization) to
> downvote it instead.
>
> The problem is: what if after a theft withdrawal is defeated, another
> theft withdrawal is done? And another, and another? This weakens the peg:
> while a theft withdrawal is on-going, a genuine withdrawal can't be posted
> (at least as I understand Sztorc's explanation). This chokes the sidechain
> withdrawal.
>
> The difference from maincoin is that attempts to choke the block are
> somewhat costly and a maincoin user can offer a higher transaction fee to
> beat the spam. If side->main is choked, no amount of sidecoin can be
> offered to beat the spammed theft transactions.
>
> I don't know, it seems like very weak security to me.
>
TLDR: a miner is most profitable if he always accepts BMM bribes, but
downvotes withdrawal transactions (WT). This obviously isn't ideal because
a withdrawal will never occur from the drivechain if enough miners employ
this strategy -- which seems to be the most profitable strategy.

-Chris


On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I think you are missing a few things.
>
> First of all, I think the security model for sidechains is the same as
> that of every blockchain
>
> People will say things, like "but with sidechains 51% hashrate can steal
> your coins!", but as I have repeated many times, this is also true of
> mainchain btc-tx.  is something else?
>
>
> There are substantial opportunity costs as well as a collective action
> problem when it comes to re-writing the mainchain.
>
> Is there anything similar for drivechains? As far as I can tell there is
> no opportunity cost to casting a malicious vote, no repercussions, and no
> collective action barrier that needs to be overcome.
>
> Unless I'm missing something I wouldn't liken the security of a drivechain
> to that of the mainchain.
>
>
> ___
> 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] Sidechains: Mainstake

[Chris Stewart via bitcoin-dev]

>For each sidechain ID, for each mainchain block, at most one sidechain
block header may be published. In addition, the sidechain block header
published on the mainchain blocks may only be published by the stake
lottery winner from the end of the previous block.

What happens if the stake winner disappears? It seems, in your scheme, that
this would cause progress to come to a screeching halt.

Our weak mitigation against a mainchain miner >50% attack is weakened
> further; now the mainchain miner with 51% hashpower need only block the
> creation of sidechain mainstake UTXOs except its own, and eventually the
> other mainstake UTXOs will time out and the miner can outright steal
> costlessly


Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate this?
This means that they cannot block the creation of mainstake utxos -- but I
guess they would still be able to block the spends of this utxo.

Another thing that is problematic with using a p2sh output is 'relocking'
the stake. Unfortunately if the p2sh script hash's aren't identical I don't
think we can guarantee they didn't spend the stake to a non stake output.
If the script hash's *are* identical then the miner can censor the
transaction that re-locks the output.

Perhaps there is a hybrid that would work, however it depends on what you
mean by 'creation'. If it is just the *initial* creation of the utxo -- and
not subsequent OP_STAKEVERIFY change outputs -- I think this strategy might
work. You just won't be able to participate in the lottery while the utxo
is nested inside the p2sh output initially.

This also brings back the problem above -- what if a stake winner
disappears -- or a miners creates the illusion they disappeared via
censorship? I guess a miner would be losing out on transaction fees.

-Chris



On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning bitcoin-dev,
>
> I have yet another sidechain proposal: https://zmnscpxj.github.io/
> sidechain/mainstake/index.html
>
> I make the below outlandish claims in the above link:
>
> 1. While a 51% mainchain miner theft is still possible, it will take even
> longer than in drivechains (either months of broadcasting intent to steal
> before the theft, or locking funds that are likely to remain locked after a
> week-long theft).
> 2. A 26% anti-sidechain miner cannot completely block all sidechain
> withdrawals as they could in drivechains.
> 3. Outside of attacks and censorship, the economic majority controls
> sidechains, without going through miners as "representatives of the
> economic majority".
> 4. With sufficient cleverness (stupidity?), proof-of-stake can be made to
> work.
>
> I hope for your consideration.  I suspect that I have not thought things
> out completely, and probably missed some significant flaw.
>
> Regards,
> ZmnSCPxj
>
> ___
> 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] Sidechain headers on mainchain (unification of drivechains and spv proofs)

[Chris Stewart via bitcoin-dev]

Hi ZmnSCPxj,

However, a lockbox on one chain is a WT on the other
> chain.  We can create a free lockbox on Ess, then use that lockbox as
> a WT on Tee, inflating TeeCoin.


I'm not sure if I follow what you are saying here. What do you mean by
'free lockbox'? I was assuming that I created an arbitrary blockchain, say
ChrisChain, that is NOT pegged to the bitcoin blockchain? I.e. the tokens
on ChrisChain are worthless. Then I create a lockbox on ChrisChain with my
worthless tokens and attempt to transfer them into TeeCoin's chain? However
this doesn't make sense with


However, this parameter is used to determine if it is a WT.  Sidechain
> consensus should require that freely-created lockboxes set this
> parameter to 0, so that a side block that creates free lockboxes where
> this parameter is non-zero is an invalid side block.  Then a sidechain
> will only treat a lockbox on another chain as a WT if the wtFlag
> parameter is nonzero.  This way, freely-created lockboxes are not
> valid WT.  Valid WT must lock actual, already unlocked coins, not
> create new locked coins.
>

because I could arbitrarily set this parameter to 0. It seems that a
sidechain upon inception should pay all of it's tokens to a single UTXO and
prevent minting of coins after that. I'm fairly certain this is what
elements does in it's genesis block.

The is unrelated to the problem above, but it will be a problem in
sidchain-headers-on-mainchain if we have a limited amount of mining slots
in the coinbase_tx output vector.

Let us assume we have a fixed set of sidechain slots in the coinbase output
vector, in this case 10. However there are 15 competing sidechains for
these 10 slots. It may be possible for sidechains (say 15 sidechains) to
compete indefinitely for these 10 slots -- causing indefinite forks. Let us
say sidechain 10 and sidechain 11 alternate block hashes in
coinbase_tx.vout[10] output. This means that a WT^ will never be considered
valid because it will appear to mainchain miners that there are competing
forks of the SAME sidechain, when in reality it is two unique sidechains
competing to mine the the limited coinbase output vector space.

-Chris

On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj  wrote:

> Good morning,
>
> Chris mentioned the use of OP_WITHDRAWPROOFVERIFY.  I've come to realize
> that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a
> sidechain-headers-on-mainchain approach.
>
> Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer
> value from the mainchain to a sidechain.  Thus, a payment to
> OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment
> to a sidechain address (or whatever is the equivalent to a sidechain
> address).
>
> Various OP_WITHDRAWPROOFVERIFY explanations exist.  Most of them include
> OP_REORGPROOFVERIFY.  With sidechain-headers-on-mainchain, however, there
> is
> no need for reorg proofs.  This is because, the mainchain can see, in real
> time, which branch of the sidechain is getting extended.  Thus if someone
> attempts to defraud a sidechain by forking the sidechain to an invalid
> state, sidechainers can immediately detect this on the mainchain and
> immediately act to prevent the invalid fork from being advanced.  After
> all, a reorg proof is really just an SPV proof that is longer than some
> previous SPV proof, that shows that the previous SPV proof is incorrect,
> by showing that the block at the specified height of the WT is not present
> on a longer SPV proof.
>
> Since sidechain-headers-on-mainchain implies merge mining of sidechains,
> with no option to have independent proof-of-work of sidechains, the
> sidechain's entire history is recorded on the mainchain, visible to all
> mainchain nodes.
>
> --
>
> An advantage of sidechain-headers-on-mainchain is a side-to-side peg
> without
> passing through the mainchain.
> That is, a 2-way peg between any two chains, whether side or main.
>
> Sidechains supporting side-to-side transfer would require supporting
> OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.
>
> We must consider a WT format (withdrawal transaction) that is compatible
> with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.
>
> ***That is, a lockbox UTXO on one chain is a WT on another chain.***
>
> Sidechains need not follow the mainchain format for its normal
> transactions, only for WT transactions that move coins across chains.
>
> For this, mainchain should also have its own "sidechain ID".  Perhaps a
> sidechain ID of 0 would be appropriate for mainchain, as its status as
> mainchain.
>
> Suppose we have two sidechains, Ess and Tee, both of which support
> side-to-side pegs.
>
> An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not
> necessarily a Tee fullnode, and vice versa.
>
> A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of
> a lockbox, pointing to the sidechain header containing WT, the merkle tree
> path to the WT 

Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

[Chris Stewart via bitcoin-dev]

Hi ZmnSCPxj,

Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length.  In the
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes can
> validate this part of the sidechain rule of "longest work chain".
>

What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.

Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.

Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code

used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.

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

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Paul correctly the OP_BV output will never hit the blockchain
then -- only the commitment in the coinbase transaction. This means no
extra data (if use lightning) has to be added to the blockchain *except*
the drivechain commitment (34 bytes in the coinbase tx vout). If this is
used for the vast majority bribes it may make the op code worth it.

In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?

-Chris

On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthc...@gmail.com> wrote:

> I still think it may be more inefficient, in equilibrium. (In other words,
> in the future steady state of Bitcoin that includes LN or something
> LN-like).
>
> Assume there are N sidechains.
>
> In the coinbase version:
> 1. There is some single event, per N, that causes nodes to notice that a
> new sidechain has been created.
> 2. Per block, there are N hash commitments (32 bytes) and N instances of
> the ratchet's block counter (2 bytes).
> 3. Per block, some node operator _may_ have BMMed the block, and a miner
> therefore might want redeem an OP Bribe that pays BTC from a sidechain node
> operator to the miner. But they are likely to negotiate the payment through
> the Lightning Network (when this is possible).
> 4. Sidechains running in SPV mode know exactly where to find the
> information they need in order to discover the "longest" chain.
>
> In the OP RETURN version:
> 1. [same] There is some single event, per N, that causes nodes to notice
> that a new sidechain has been created.
> 2. [+30 bytes (+more?)] Per block, there are N hash commitments (32 bytes)
> and also N prevBlockHashes (32 bytes). Also, to make this transaction,
> someone needs to spend something in the UTXO set (or select no inputs in a
> kind of 'hollow transaction'), whereas one coinbase will always exist per
> block.
> 3. [same] No need for a new transaction.
> 4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain per
> block, sidechains need just a merkle tree path, but they don't necessarily
> know where it is. They must store extra [?] data to help them find the
> data's location?
>
>
> On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
>
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
>
> I think that that is the purpose of Rusty's soft fork rule about only
> including one per sidechain -- miners would have one "slot" per sidechain,
> and they would therefore have an incentive to make the slot count, and
> would be only selecting the highest fee txn to fill each slot.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart via bitcoin-dev]

Hi Greg,

The safest way to ensure everyone's protection to make sure *no one can do
anything*. Then we will ALL be safe ;).

>If so, please leave, you are compromising Bitcoin's security.

Ok, let's calm down.

>If I design a car that has a button that randomly causes the brakes to
give out if pressed, is that a good idea? Can I justify pushing for such a
"feature" just because it's "opt-in"?

It would be more like "should we allow a car on the road if we know
statistically that our brakes give out in every 1/100,000,000 cars"? There
is security risks with everything in life -- we need to quantify the risk
to see if it is worth taking. I think Paul has been pretty upfront about
the risks of his model. I think you did a good job of demonstrating it in
the email I cited too.

>It is how *insecure* systems are designed.

By your account bitcoin is already insecure then -- it allows anyone can
spend outputs that can be claimed by miners.

>Sure, happy to, as soon as I have it written up in detail.

I look forward to this!

-Chris

On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect  wrote:

> Dear Chris,
>
> I think this is an unfair characterization. You have to opt into using
> drivechains.
>
>
> I have heard this nonsense repeated countless times in order to justify
> adopting Drivechain.
>
> This is not how security works.
>
> A child can "opt-in" to using a loaded gun, but is it a good idea to make
> it easy for them to do that?
>
> No.
>
> This is effectively the same thing Drivechains is doing.
>
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin
> users to give their Bitcoins to miners.
>
> Does that sound like a good idea to anyone?
>
> If so, please leave, you are compromising Bitcoin's security.
>
> Security is about making it difficult to shoot yourself in the face.
>
> If I design a car that has a button that randomly causes the brakes to
> give out if pressed, is that a good idea? Can I justify pushing for such a
> "feature" just because it's "opt-in"?
>
> No. That is fallacy.
>
> It is not how secure systems are designed.
>
> It is how *insecure* systems are designed.
>
> Care to share? I'm unaware if there is.
>
>
> Sure, happy to, as soon as I have it written up in detail.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 12, 2017, at 12:19 PM, Chris Stewart  wrote:
>
> Hi Greg,
>
> >Here, you admit that the security of the sidechains allows miners to
> steal bitcoins, something they cannot do currently.
>
> If I put my coins in an anyone can spend output, a miner will take them.
> They can do this today. I suggest you try it if you don't believe me :-).
> You have to be more specific with contract types instead of generically
> talking about 'all contracts ever'.
>
> > Drivechain is an unmistakeable weakening of Bitcoin's security
> guarantees. This you have not denied.
>
> I think this is an unfair characterization. You have to opt into using
> drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
> drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
> has stated all along), drivechain outputs have a different security model
> than other contracts. Namely they are controlled by miners. I think we can
> all agree this is unfortunate, but it is the current reality we live in. I
> look forward to the day we can solve the 'ownership' problem so we can have
> trustless interoperable blockchains, but that day is not today.
>
> As a reminder, most users will not have to go through the drivechain
> withdrawal process. Most withdrawals will be done via atomic swaps.
>
> >There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Care to share? I'm unaware if there is.
>
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.
> html
>
> Everyone should re-read this email though, this is something that could
> happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
> I guess we can argue if there is any difference between an obvious robbery
> vs a hidden robbery, but I think if we have to pick one or the other the
> choice is clear to me. Other designs (that I'm aware of) for sidechains had
> attack vectors that weren't so obvious.
>
> -Chris
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Chris Stewart via bitcoin-dev]

Hi Greg,

>Here, you admit that the security of the sidechains allows miners to steal
bitcoins, something they cannot do currently.

If I put my coins in an anyone can spend output, a miner will take them.
They can do this today. I suggest you try it if you don't believe me :-).
You have to be more specific with contract types instead of generically
talking about 'all contracts ever'.

> Drivechain is an unmistakeable weakening of Bitcoin's security
guarantees. This you have not denied.

I think this is an unfair characterization. You have to opt into using
drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a
drivechain output. As Pieter Wuille stated earlier in this thread (and Paul
has stated all along), drivechain outputs have a different security model
than other contracts. Namely they are controlled by miners. I think we can
all agree this is unfortunate, but it is the current reality we live in. I
look forward to the day we can solve the 'ownership' problem so we can have
trustless interoperable blockchains, but that day is not today.

As a reminder, most users will not have to go through the drivechain
withdrawal process. Most withdrawals will be done via atomic swaps.

>There is no reason to weaken Bitcoin's security in such a dramatic
fashion. Better options are being worked on, they just take time.

Care to share? I'm unaware if there is.

>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html

Everyone should re-read this email though, this is something that could
happen. Paul's design makes it so that if this occurs it is *VERY* obvious.
I guess we can argue if there is any difference between an obvious robbery
vs a hidden robbery, but I think if we have to pick one or the other the
choice is clear to me. Other designs (that I'm aware of) for sidechains had
attack vectors that weren't so obvious.

-Chris



On Tue, Jul 11, 2017 at 6:12 PM, Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Paul,
>
> There is a difference between replying to an email, and addressing the
> issues that were brought up in it.
>
> I did read your reply, and I chose not to respond to it because it did not
> address anything I said.
>
> Here's an example:
>
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.
>
>
> Here, you admit that the security of the sidechains allows miners to steal
> bitcoins, something they cannot do currently.
>
> You next tried to equate three different types of theft, what you called
> "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
>
> I do not think that any of the three stands out as being categorically
> worse than the others
>
>
> To anyone who understands bitcoin, there is a very clear, unmistakeable
> difference between double-spending ("Classic Theft"), and *ownership* of
> the private key controlling the bitcoins.
>
> Similarly, to anyone who understands bitcoin, there is also a very clear,
> unmistakeable difference between censorship ("Channel Theft"), and
> *ownership* of the private key controlling the bitcoins.
>
> The entire email was a very long-form way of admitting to all of the
> issues that were raised in the previous email, while making it sound like
> you had addressed the issues.
>
> I am not sure how else to respond to that email, given that none of the
> issues were really addressed.
>
> Drivechain is an unmistakeable weakening of Bitcoin's security guarantees.
> This you have not denied.
>
> There is no reason to weaken Bitcoin's security in such a dramatic
> fashion. Better options are being worked on, they just take time.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jul 11, 2017, at 3:57 PM, Paul Sztorc  wrote:
>
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>
> Dear Paul,
>
> Drivechain has several issues that you've acknowledged but have not,
> IMO, adequately (at all really) addressed [1].
>
>
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014609.html
>
> Adopting DC would be an irreversible course of action,
>
>
> This is false -- it is easily reversible with a second soft fork.
>
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
>
> Paul
>
>
>
>
>
> 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

Hi Russell/ZmnSCPxj,

I think you guys are right. The only problem I can see with it is
replaceability of the bribe transaction. If the 'Bribe' is the fee on the
transaction it isn't clear to me what the best way to replace/remove it is.

If we have the amount in the output (instead of the fee) we can construct a
contract like this

OP_IF   OP_BV OP_ELSE OP_DUP OP_HASH160 
OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF

That way, if the miner does *not* include your bribe, he is *still*
incentived to include your redemption.

If we decide to only an OP_RETURN output, we can replace the 'bribe'
transaction with a transaction that double spends the prevout. Thus if your
'bribe' transaction is not included in a block, a miner can still include
your double spend transaction to refund yourself (and a miner gets to
collect his normal mining fee).

I'm not 100% sure if there are mempool policies that would reject this
double spend tx or not -- but I guess this is an implementation detail not
a high level design one.

Also if there is not a commitment in the coinbase transaction it may be
harder to search for drivechain commitments. I've been floating around the
idea of a 'drivechain commitment tx' so we could easily see where all of
the voting is happening for withdrawal transactions -- but that is very
much up in the air.

On Wed, Jul 12, 2017 at 1:00 PM, Chris Stewart 
wrote:

> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
> If we have the amount in the output (instead of the fee) we can construct
> a contract like this
>
> OP_IF   OP_BV OP_ELSE OP_DUP OP_HASH160 
> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF
>
> That way, if the miner does *not* include your bribe, he is *still*
> incentived to include your redemption.
>
> If we decide to only an OP_RETURN output, we can replace the 'bribe'
> transaction with a transaction that double spends the prevout. Thus if your
> 'bribe' transaction is not included in a block, a miner can still include
> your double spend transaction to refund yourself (and a miner gets to
> collect his normal mining fee).
>
> I'm not 100% sure if there are mempool policies that would reject this
> double spend tx or not -- but I guess this is an implementation detail not
> a high level design one.
>
> Also if there is not a commitment in the coinbase transaction it may be
> harder to search for drivechain commitments. I've been floating around the
> idea of a 'drivechain commitment tx' so we could easily see where all of
> the voting is happening for withdrawal transactions -- but that is very
> much up in the air.
>
> -Chris
>
> On Wed, Jul 12, 2017 at 8:39 AM, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> In any case, let me propose actual improvements to the OP_BRIBEVERIFY
>>> proposal:
>>>
>>> 1.  Remove the necessity of coinbase commitments.  The miner commits to
>>> the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY
>>> anyway.  That way the h* commitment occurs only once in the block, in the
>>> transaction that does the OP_BRIBEVERIFY.  In addition, there is no need to
>>> impose particular ordering on the coinbase outputs, which would be
>>> problematic as pointed out by others, for example if the miner is
>>> interested only in merge mining for sidechain id #35 and nobody else.
>>>
>>> 2.  When verifying a block, keep a set of sidechain ID's.  When
>>> processing a transaction in that block with OP_BRIBEVERIFY, check if the
>>> sidechain ID is in that set.  If not in that set, add it to that set and
>>> continue script processing.  If already in the set, fail the script
>>> processing.  This ensures that at most one OP_BRIBEVERIFY exists for each
>>> sidechain_id in a mainchain block.
>>>
>>
>> At this point can we eliminate the need to use the scripting system at
>> all and just use a special, currently non-standard, OP_RETURN output to
>> hold the sidechain_id and h* instead?  We can soft fork in a rule that at
>> most one such output can appear in a block per sidechain_id.
>>
>> ___
>> 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] Updating the Scaling Roadmap

[Chris Stewart via bitcoin-dev]

Concept ACK.

I think you are overstating the readiness of drivechains though. I think
the optimistic estimate for drivechains to be ready for bitcoin core is a
year out from today. More likely the date should be early 2018. Still a lot
of work to be done! :-)

Also I don't know if I would put a hard fork suggestion in the scaling map.
If drivechains are successful they should be viewed as the way we scale --
not hard forking the protocol. Do you still have capacity concerns if
drivechains are successful?

-Chris

On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Summary
> =
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
>   Beginning of New ("July 2017") Roadmap Draft 
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately, has been completed and awaits
> activation (multiple BIPS). It is estimated to increase capacity by a
> factor of 2.2. It also improves scalability in many ways. First, SW
> includes a fee-policy which encourages users to minimize their impact on
> the UTXO set. Second, SW achieves linear scaling of sighash operations,
> which prevents the network from crashing when large transactions are
> broadcast. Third, SW provides an efficiency gain for everyone who is not
> verifying signatures, as these no longer need to be downloaded or
> stored. SegWit is an enabling technology for the Lightning Network,
> script versioning 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

Hi ZmnSCPxj,


In my scheme, if you read carefully through the pseudocode, a block list
> node is valid only if its block is valid.
>

It seems this is a contradiction against the "blind" part of blind merge
mining. How can a bitcoin blockchain node enforce this without tracking the
sidechain?

Basically, in my scheme, the OP_RETURN data *is* the sidechain block
> headers stored on the mainchain.  To save space, the sidechain block
> headers are reduced to only the previous-block-header commitment and the
> current-block-data commitment.  All of the other data you would want to put
> in the block header (e.g. UTXO set commitment, signalling bits,
> time-of-day...) would be part of the current-block-data instead of the
> block header.  Thus if the current-block-data is invalid the sidechain
> block header is invalid and another sidechain block header based on the
> previous block header will be searched for.


It seems both of our schemes need to include 2 32 bit hashes in the
blockchain. Your scheme needs a previous block header hash and the current
block header hash, while mine includes the current block header hash
twice.  We can just commit to all that information via the block header
hash and if a sidechain node lies to us will we are doing IBD the hashes
won't match with what was included in the bitcoin blockchain.

I'll follow your discussion with Paul about sidechain reorgs, but I think
his proposal is more desirable -- it follows what actually happens in the
bitcoin mining process where we *can* have chain splits when miners
simultaneously find a block. Other miners will pick one of the two blocks
to mine on top of and eventually one chain will become longer than the
other. Therefore that chain will have it's block's orphaned and the
miners/nodes following the dead chain will reorg on top of the longest
chain.

In Paul's scheme, we replace PoW with a bribe. At the conceptual level
these are somewhat similar. In PoW a miner is willing to pay a certain
amount of money (on electricity) to try to find a bitcoin block. With
OP_BRIBEVERIFY a sidechain miner is willing pay a certain amount of money
to find a block.

In PoW, there is nothing at the software level that says a miner cannot
just decide to build on a old block. I could decide to build on the genesis
block if I wanted to. Obviously this is a stupid idea as I'll never
overtake the bitcoin blockchain with 8 years of PoW behind it -- but it
doesn't mean I couldn't try if I wanted too. Your scheme from what I
understand prevents this from happening -- and I don't think that is
desirable. You might be able to make an argument that a rich attacker can
*stall* mining progress on the drivechain, but I think the same argument
can be made with a rich miner on the bitcoin blockchain as well. I think
miners have threatened to do that if BIP148 caused a chain split.

Can you link to the aforementioned pseudocode? I must have missed it on the
mailing list.

-Chris

On Tue, Jul 4, 2017 at 2:21 AM, ZmnSCPxj  wrote:

> Good morning Paul, Chris, and CryptAxe,
>
> @Paul
>
> >> >Your way is actually very similar to mine. Mine _forces_ the bribe to
> be
> >> >in the earliest txn (the coinbase) and to only occur once. Yours
> doesn"t
> >> >do anything to refund the briber, if the sidechain (but not the
> >> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >> >parent is extended while the mainchain proceeds normally). This creates
> >> >additional risk.
> >>
> >> I don"t understand this part. In my scheme, a sidechain cannot
> >> reorganize unless the mainchain reorganizes, since the consensus loop
> >> only cares about matching the current block; it ignores splits and
> >> does not consider them valid.
> >
> >If I"ve understood you correctly, you have said that each OP Return
> >links the (ex)-latest block to a brand new block, and that whichever
> >message of this kind comes first (in the mainchain) wins and the rest
> >are discarded.
> >
> >So what if I had a sidechain represented by a jumble of capital letters,
> >discarded entries as lowercase letters.
> >
> >Mainchain Block #21: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
> >Mainchain Block #22: [Q --> H], [Q --> z],
> >Mainchain Block #23: [H --> F]
> >Mainchain Block #24: [F --> J], [F -->w]
> >Mainchain Block #25: [H --> P], [J -->x]
> >Mainchain Block #26: [P --> D]
> >
> >Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
> >competing chain {{ Q --> H --> P --> D }} ?
>
> No, because at block #20005, the topmost sidechain block is J, not H, and
> the H->P will not be considered as valid -- only the J->x is valid, even
> though H->P comes first.
>
> Please see the pseudocode I sent before in detail and consider how it will
> work with your given mainchain blocks example.
>
>
> >> But I suppose you are considering something like the Ethereum
> >> mutability feature, which I do not think is something you would want
> >> 

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

>I don't understand this part.  In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.

Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
if a attacker pays a large fee to have his *invalid* block hash included in
the bitcoin mainchain? Would this block *have* to be included in the
sidechain's blockchain forever since *it was* included in bitcoin
blockchain?

>Do you not provide a single sidechain's h* twice in the block?  Once in
the coinbase and once in the briber's separate transaction?

Yes, my BIP proposal does this.

>In my scheme at least there is no indicator byte -- the "previous block"
hash is the indicator of which sidechain it is extending.  From your other
emails on this list, it seems the ratchet is for withdrawals from sidechain
to mainchain?  If so, should it not only appear in only some of the
sidechains (the ones which are currently doing some withdrawal?)?

Maybe I am missing something here, but why we do *explicitly* commit to the
previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
If a drivechain node tries to sync the drivechain from bitcoin's commitment
headers, it will invalidate that block since
the block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the OP_BV
output. In general, I don't think we should assume these commitment headers
dictate the strict ordering of blocks on the sidechain -- only potential
blocks that
*might* be valid. To guarantee full validity drivechain nodes will have to
download the full block and figure out if they follow all of the consensus
rules.

This is sort of like headers first sync in bitcoin core:

https://bitcoin.org/en/developer-guide#headers-first

-Chris

On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj  wrote:

> Good Morning Paul,
>
> >It seems that, in your version, the "bribers" would react to the scheme
> >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
> >fee per Kb) is low.
> >
> >In short, there would be many bribe-attempts (each of which would take
> >up space in mainchain blocks), almost all of which would be unsuccessful.
> >
> >In turn, miners would likely react to this, and try to improve the state
> >of affairs by offering users the privilege of occupying transaction slot
> >#2 (ie, the one right after the coinbase). Users would need to trust
> >miners for this, which introduces a cost friction which is pure
> >deadweight loss. And, it might be easier for larger/older miners to be
> >trustworthy than smaller/newer ones.
>
> I understand.
>
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part.  In my scheme, a sidechain cannot reorganize
> unless the mainchain reorganizes, since the consensus loop only cares about
> matching the current block; it ignores splits and does not consider them
> valid.
>
> But I suppose you are considering something like the Ethereum mutability
> feature, which I do not think is something you would want in a sidechain.
>
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block?  Once in
> the coinbase and once in the briber's separate transaction?
>
> In my scheme at least there is no indicator byte -- the "previous block"
> hash is the indicator of which sidechain it is extending.  From your other
> emails on this list, it seems the ratchet is for withdrawals from sidechain
> to mainchain?  If so, should it not only appear in only some of the
> sidechains (the ones which are currently doing some withdrawal?)?
>
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

[Chris Stewart via bitcoin-dev]

Hi Russell,

>I haven't really been following the drivechain discussion; I have found
the documentation about how drivechains are supposed to work scattered and
difficult to follow. So, without advocating for or against this proposal,
I'd also suggest that adding an opcode is not the best way to implement
this bribe.

Despite the flaws in this draft BIP, the goal is to start consolidating
this information into a more compact format. This BIP is *only*
meant to address the Blind Merging Mining Process of drivechains. It does
*not* address the withdrawal process from drivechain -> bitcoin.

>The problem I see is that to send a bribe one must first post a
transaction to a script that uses the OP_BRIBE code that fixes the critical
hash (and the sidechain id), and then a second transaction is needed to pay
the bribe to the miner.

That is intentional, this allows for a competitive process (like bitcoin
mining) for a block to be 'found' on the sidechain. The OP_BV output that
rewards
the bitcoin miner the most amount of money should be the one that is
included in the bitcoin blockchain. If I understand your scheme correctly,
you are
assuming the the bitcoin miner is *also* following the sidechain --
Sztorc's scheme does not make this assumption. The *number one goal* of BMM
is to *minimize* the resource burden on bitcoin miners for mining on a
drivechain.

To gmaxwell/luke-jr,

I agree my commitment scheme is flawed. Thanks for pointing it out. Is
there any way we could manipulate a coinbase transaction
into spending these OP_BV outputs? According to instagibbs, and AFIACT he
is right, we cannot have coinbase transactions
spend any outputs in previous blocks without a hard fork. This is
unfortunate because it might make more sense for the coinbase transaction
to spend these OP_BV outputs. We could design the coinbase transaction's
scriptSig to push the critical hash onto the stack and
place an OP_EQUAL on the OP_BV output to verify they were equal.
If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
correctly, I *think*
this solution might fix that as well.

Another way we could fix this is by *fixing* the drivechain indices.
Therefore the mining rewards and witness commitments must
*not* occupy one of those indices -- but can occupy any other indice in the
coinbase output.
This would give us future flexibility for committing to new soft forks. For
instance, we would say
the mining reward must *not* be index 0 of the coinbase transaction, but
can occupy index 1 - 256. The same would apply for witness commitments.

-Chris

On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor 
wrote:

> I haven't really been following the drivechain discussion; I have found
> the documentation about how drivechains are supposed to work scattered and
> difficult to follow. So, without advocating for or against this proposal,
> I'd also suggest that adding an opcode is not the best way to implement
> this bribe.
>
> The problem I see is that to send a bribe one must first post a
> transaction to a script that uses the OP_BRIBE code that fixes the critical
> hash (and the sidechain id), and then a second transaction is needed to pay
> the bribe to the miner.
>
> I suggest instead to use a 0 output value with some currently non-standard
> OP_RETURN output script that specifies the critical hash (and the sidechain
> id), similar to ZmnSCPxj's idea.  The difference is that I we would
> soft-fork a rule that says that such an output is only legal when a miner
> places the same critical hash suitably in their coinbase output.
>
> OP_RETURN outputs are prunable from the UTXO set.  The special bribe
> output can be fixed to 0 value because the bribe will be paid using the
> transaction's fees.  To perform a bribe, a user creates and signs a
> transaction containing one (or more) of these special bribe outputs.  The
> fee of this transaction constitutes the bribe, and any change the user has
> can be sent back to themselves.  This way only a single transaction is
> required to make a bribe.  I didn't really understand the bribe refund
> mechanism, but I think the fact that the bribe can be done in a single
> transaction this way alleviates any need for bribe refunds.
>
> Hopefully I have understood the goal of this proposal.
>
>
> On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi ZmnSCPxj,
>>
>> It seems that, in your version, the "bribers" would react to the scheme
>> in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
>> fee per Kb) is low.
>>
>> In short, there would be many bribe-attempts (each of which would take
>> up space in mainchain blocks), almost all of which would be unsuccessful.
>>
>> In turn, miners would likely react to this, and try to improve the state
>> of affairs by offering users the privilege of occupying transaction slot
>> #2 (ie, the one right after the coinbase). Users would need to 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart via bitcoin-dev]

>
> Since the sidechain has the sidechain BMM headers that they want the LD
> (bribe) data for, I think that they could specifically request LD data
> relevant only to that sidechain by providing a list of hashes to the
> mainchain, and the mainchain can return a list of boolean values telling
> the sidechain if the LD data exists. That way the data never even has to
> go over the network, just a verification that it exists on the mainchain
> and
>

Since you seem to be talking about the initial block download process for
the drivechain. It seems that we might as well request the set of *valid*
blocks from a bitcoin peer first, since at the end of the day they are in
control of the mining process on the sidechain. Here is what I envision:

   1. Request all hashes for sidechain from a bitcoin peer
   2. Request all sidechain block header's for the hashes the bitcoin peer
   gave us
   3. Order the set of sidechain block headers by looking at hashPrevBlock.
   4. Request full sidechain blocks and start validating against the
   consensus rule set of the sidechain


we can drop the sidechain_id from the script.

I agree the 'sidechain_id' is unneeded in the coinbase tx output. We should
just fix these based on index. This should be reflected in my latest commit
if we are talking about the same thing:
https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254


and have the sidechain handle filtering out invalid LD data /
> only requesting the verification of LD data that they know to be valid
> as far as chain order goes.
>

 I agree, the whole point of BMM is to have bitcoin miners indifferent to
what happens in the sidechain (although Paul argues in a wonky way they do
care sort of). If there is an invalid (in the sense the block it represents
does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
that a 'blind' bitcoin miner will choose the one that pays them the most
money.

>I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

I'm fairly certain you are right. It just feels like we should be able to
exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
I'll have to think about this more, maybe some one else can come up with
something clever that exploits that fact.

On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewart  wrote:

> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that they could specifically request LD data
>> relevant only to that sidechain by providing a list of hashes to the
>> mainchain, and the mainchain can return a list of boolean values telling
>> the sidechain if the LD data exists. That way the data never even has to
>> go over the network, just a verification that it exists on the mainchain
>> and
>>
>
> Since you seem to be talking about the initial block download process for
> the drivechain. It seems that we might as well request the set of *valid*
> blocks from a bitcoin peer first, since at the end of the day they are in
> control of the mining process on the sidechain. Here is what I envision:
>
>1. Request all hashes for sidechain from a bitcoin peer
>2. Request all sidechain block header's for the hashes the bitcoin
>peer gave us
>3. Order the set of sidechain block headers by looking at
>hashPrevBlock.
>4. Request full sidechain blocks and start validating against the
>consensus rule set of the sidechain
>
>
> we can drop the sidechain_id from the script.
>
> I agree the 'sidechain_id' is unneeded in the coinbase tx output. We
> should just fix these based on index. This should be reflected in my latest
> commit if we are talking about the same thing: https://github.com/
> Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a9
> 7710feb032/src/script/script.cpp#L254
>
>
> and have the sidechain handle filtering out invalid LD data /
>> only requesting the verification of LD data that they know to be valid
>> as far as chain order goes.
>>
>
>  I agree, the whole point of BMM is to have bitcoin miners indifferent to
> what happens in the sidechain (although Paul argues in a wonky way they do
> care sort of). If there is an invalid (in the sense the block it represents
> does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
> pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
> that a 'blind' bitcoin miner will choose the one that pays them the most
> money.
>
> >I might be wrong but I thought that OP_RETURN outputs do not go into the
> UTXO set. Anyone else want to chime in?
>
> I'm fairly certain you are right. It just feels like we should be able to
> exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
> I'll have to think about this more, maybe some one else can come up with
> 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart via bitcoin-dev]

>OP_RETURN  

I think it is redundant here to have the , we can implicitly
assume what the sidechain_id is since we have a fixed set of drivechains.
I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc.
CryptAxe has specific indexes defined already in his implementation:
https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30
.

I think it would be wise to include a version byte to allow us to upgrade
this commitment structure in the future. Similar to how witness program's
are now versioned.

>   OP_BRIBE_VERIFY

If  is an argument that OP_BRIBE_VERIFY takes, doesn't that
mean the mainchain miner has to validate this *is* the actual block height
on the sidechain? Does that take the 'blindness' away from BMM?

Overall, I think we need to work on the commitment structure to the
coinbase tx. If I understand the current implementation correctly we can
have up to 256 OP_RETURNs embedded in the coinbase tx signifying new blocks
mined on drivechains.. this seems less than ideal. It might be prudent to
make these outputs ANYONECANSPEND, and then have miners spending these
outputs to themselves for every block mined.. maybe this doesn't have a
benefit over using OP_RETURNs though?

The structure could be something like:
 

and then in a subsequent block the miner spends that output to themselves.
I will admit I'm not super familiar with how OP_RETURNs work with the UTXO
set -- maybe this scheme doesn't have any benefit.

-Chris

On Wed, May 24, 2017 at 3:50 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc  wrote:
>
>>
>> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
>> probably the most human-readable description.
>>
>
> I guess I was looking for the detail you get in the code, but without
> having to read the code.
>
> My quick reading gives that the sidechain codes (critical hashes) are
> added when a coinbase is processed.
>
> Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
> a potential critical hash.
>
> When the block is processed, the key value pair (hash, block_height) is
> added to a hash map.
>
> The OP_BRIBE opcode checks that the given hash is in the hash map and
> replaces the top element on the stack with the pass/fail result.
>
> It doesn't even check that the height matches the current block, though
> there is a comment that that is a TODO.
>
> I agree with ZmnSCPxj, when updating a nop, you can't change the stack.
> It has to fail the script or do nothing.
>
> OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
> coinbase, or cause a script failure otherwise.
>
> Another concern is that you could have multiple bribes for the same chain
> in a single coinbase.  That isn't fair and arguably what the sidechain
> miner is paying for is to get his hash exclusively into the block.
>
> I would suggest that the output is
>
> OP_RETURN  
>
> Then add the rule that only the first hash with a particular sidechain id
> actually counts.
>
> This forces the miner to only accept the bribe from 1 miner for each
> sidechain for each block.  If he tries to accept 2, then only the first one
> counts.
>
> OP_BRIBE_VERIFY could then operate as follows
>
>OP_BRIBE_VERIFY
>
> This causes the script to fail if
>does not match the block height, or
>is not the hash for the sidechain with , or
>   there is no hash for that sidechain in the block's coinbase
>
> If you want reduce the number of drops, you could serialize the info into
> a single push.
>
> This has the advantage that a sidechain miner only has to pay if his block
> is accepted in the next bitcoin block.  Since he is the only miner for that
> sidechain that gets into the main bitcoin block, he is pretty much
> guaranteed to form the longest chain.
>
> Without that rule, sidechain miners could end up having to pay even though
> it doesn't make their chain the longest.
>
> How are these transactions propagated over the network?  For relaying, you
> could have the rule that the opcode passes as long as  is
> near the current block height.  Maybe require that they are in the future.
> They should be removed from the memory pool once the block height has
> arrived, so losing miners can re-spend those outputs.
>
> This opcode can be validated without needing to look at other blocks,
> which is good for validating historical blocks.
>
> I am still looking at the deposit/withdrawal code.
>
> ___
> 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] I do not support the BIP 148 UASF

[Chris Stewart via bitcoin-dev]

>Regarding this last point I was under the impression that if Segwit did
not activate by November then core was going to move on, is that no longer
the case, does the core team plan on trying to activate Segwit in some
other way?

Since block size seems to be the controversial issue, AFAIK we *could*
remove the block size increase (by removing the discount on signature
data). This discount was put in place for two reasons

1.) It allows for a block size increase
2.) It makes it more expensive to create UTXOs. UTXO bloat is a problem on
the bitcoin network and segwit was an elegant way to make the network
appreciate their real cost in terms of hardware/RAM.

We would still get the benefits of:
1.) Tx malleability elimination
2.) Script versioning

-Chris

On Fri, Apr 14, 2017 at 9:01 PM, Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
>
> Regarding this last point I was under the impression that if Segwit did
> not activate by November then core was going to move on, is that no longer
> the case, does the core team plan on trying to activate Segwit in some
> other way?
>
> I am also curious, but has there been a softfork, hardfork, or other major
> census change that was not rolled out and done by the core team? I only
> mention this because BIP148, if it goes ahead (and is successful), would be
> the first time a consensus change occurs outside of the core developers --
> but again I am not an expert on the history of changes and could be wrong,
> I only bring this up because core developers have in the past stressed they
> are a part of the bitcoin ecosystem and not the drivers of it (at least
> that is the ideal it seems).
>
> My impression is that the community is ready for this and wants it, and if
> that impression is correct it will go ahead. No one knows the future, and
> simply assuming it's better to be slow and methodical isn't especially
> convincing. Technology is in someways the history of failure, we like to
> celebrate the seemingly sudden breakthroughs and successes but it's rare
> that the original innovator retains a monopoly on their invention, more
> often it becomes quickly refined and iterated upon as market forces take
> hold to bring costs down and other external political issues
> take precedence, all this is say that in ten years everyone could be
> chuckling over the 3 year bitcoin scaling debate, or they could be using
> litecoin, or ethereum or some other crypto coin, or something entirely
> different, no one knows.
>
> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I do not support the BIP148 UASF for some of the same reasons that I
>> do support segwit:  Bitcoin is valuable in part because it has high
>> security and stability, segwit was carefully designed to support and
>> amplify that engineering integrity that people can count on now and
>> into the future.
>>
>> I do not feel the the approach proposed in BIP148 really measures up
>> to the standard set by segwit itself, or the existing best practices
>> in protocol development in this community.
>>
>> The primary flaw in BIP148 is that by forcing the activation of the
>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>> of disruption.
>>
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>>
>> Older nodes will not include segwit spends, and so their blocks will
>> not be invalid even if they do not have segwit support. They can
>> upgrade to it on their own schedule. The only risk non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it, a risk many miners already
>> frequently take with spy-mining.
>>
>> I do not think it is a horrible proposal: it is better engineered than
>> many things that many altcoins do, but just not up to our normal
>> standards. I respect the motivations of the authors of BIP 148.  If
>> your goal is the fastest possible segwit activation then it is very
>> useful to exploit the >80% of existing nodes that already support the
>> original version of segwit.
>>
>> But the fastest support should not be our goal, as a community-- there
>> is always some reckless altcoin or centralized system that can support
>> something faster than we can-- trying to match that would only erode
>> our distinguishing value in being well engineered and stable.
>>
>> "First do no harm." We should use the least disruptive mechanisms
>> available, and the BIP148 proposal does not meet that test.  To hear
>> some people-- non-developers on reddit and such-- a few even see the
>> forced orphaning of 148 as a virtue, that it's punitive for
>> 

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Chris Stewart via bitcoin-dev]

>Criticizing 148 without suggesting a specific alternative leaves the
community in disarray.

I really disagree with this sentiment, you don't need to provide
alternatives to criticize a technical proposal. I don't like this "active
segwit at all costs" theme that has been going around the community. I am a
fan of segwit, but we shouldn't push things through in an unsafe manner.

>If 148 causes orphaning and a fork, I don't think such really matters in
the long term.  The non-SegWit miners will probably just quickly give up
their orphans once they realize that money users like being able to have
non-mutable TX IDs.  If they do create a long lasting branch... well that
is good too, I'd be happy to no longer have them in our community.  Good
luck to them in creating a competitive money, so that we can all enjoy
lower transaction fees.

This seems like a lot of reckless hand waving to me.

Food for thought, why are we rejecting *all* blocks that do not signal
segwit? Can't we just reject blocks that *do not* signal segwit, but *do*
contain segwit transactions? It seems silly to me that if a miner mines a
block with all pre segwit txs to reject that block. Am I missing something
here?

-Chris

On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Gregory Maxwell,
>
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
>
> I know you are emphasizing patience.  But at the same time, with your
> patience we are allowing ourselves to get dicked for longer than necessary.
>
> I think that core could easily develop code that could create a
> solid/reliable date/height based activation to allow miners to create
> SegWit block candidates and having nodes fully verify them.  Shaolinfry is
> the only person Ive seen actually make such a proposal:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/014049.html.  His makes it so that SegWit default gets
> activated at the end of the BIP9 signalling timeframe instead of default
> leaving it non-activated.
>
> I agree that 148 is is not ideal.  Non-SegWit signaling blocks are not a
> Denial of Service, given that other activation methods are available.
> Someone just needs to code something up that is better that we can all use
> in a satisfying time frame.  So far 148 is the most practical and reliable
> method I'm aware of.
>
> If 148 causes orphaning and a fork, I don't think such really matters in
> the long term.  The non-SegWit miners will probably just quickly give up
> their orphans once they realize that money users like being able to have
> non-mutable TX IDs.  If they do create a long lasting branch... well that
> is good too, I'd be happy to no longer have them in our community.  Good
> luck to them in creating a competitive money, so that we can all enjoy
> lower transaction fees.
>
> SegWit has already undergone enough testing.  It is time to activate it.
>
> Cheers,
> Praxeology Guy
>
> ___
> 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] Requirement for pseudonymous BIP submissions

[Chris Stewart via bitcoin-dev]

>I think this is an excellent idea. I consider myself to be extremely
data-driven and logical in my thinking, and have still fallen victim to
thinking "oh great, what's  on
about now?" when seeing something posted or proposed.

I think we need to all recognize we are only humans -- thus susceptible to
our emotions influencing our decisions. The notion of identity is an easy
way to form judgements for/against an idea before thoroughly vetting it.

I also think a by product of this would be to curb reddit/twitter trolls
from talking about these protocol changes. It is a much less juicy story if
you have to say "9458b7f9f76131f18823d73770e069d55beb271b created a BIP to
propose a block size increase" compared to "Satoshi Nakamoto created a BIP
to propose a block size increase".

Note about the OP:

"The hash “6f3…9cd0” is just my..." should really say "The hash
'9458...271b' is just my.." Forgot to change the hash this morning.

On Sat, Mar 18, 2017 at 11:57 AM, Andrew Johnson <andrew.johnso...@gmail.com
> wrote:

> I think this is an excellent idea. I consider myself to be extremely
> data-driven and logical in my thinking, and have still fallen victim to
> thinking "oh great, what's  on
> about now?" when seeing something posted or proposed.
>
> And vice versa, it prevents people from being more partial to a bad or not
> so great idea simply because it was posited by someone they hold in high
> regard.
>
> Simple, yet effective.  I would actually even go a step further and say
> that all BIPs should be done this way as a matter of procedure, I can't
> think of a downside.
>
>
> On Sat, Mar 18, 2017 at 10:46 AM Chris Stewart via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> As everyone in the Bitcoin space knows, there is a massive scaling debate
>> going on. One side wants to increase the block size via segwit, while the
>> other side wants to increase via hard fork. I have strong opinions on the
>> topic but I won’t discuss them here. The point of the matter is we are
>> seeing the politicization of protocol level changes. The critiques of these
>> changes are slowly moving towards critiques based on who is submitting the
>> BIP -- not what it actually contains. This is the worst thing that can
>> happen in a meritocracy.
>>
>> *Avoiding politicization of technical changes in the future*
>>
>> I like what Tom Elvis Judor did when he submitted his MimbleWimble white
>> paper to the technical community. He submitted it under a pseudonym, over
>> TOR, onto a public IRC channel. No ego involved — only an extremely
>> promising paper. Tom (and Satoshi) both understood that it is only a matter
>> of time before who they are impedes technical progress of their system.
>>
>> I propose we move to a pseudonymous BIP system where it is required for
>> the author submit the BIP under a pseudonym. For instance, the format could
>> be something like this:
>>
>> BIP: 1337
>>
>> Author: 9458b7f9f76131f18823d73770e069d55beb2...@protonmail.com
>>
>> BIP content down here
>>
>> The hash “6f3…9cd0” is just my github username, christewart, concatenated
>> with some entropy, in this case these bytes: 639c28f610edcaf265b47b0679986d
>> 10af3360072b56f9b0b085ffbb4d4f440b
>>
>> and then hashed with RIPEMD160. I checked this morning that protonmail
>> can support RIPEMD160 hashes as email addresses. Unfortunately it appears
>> it cannot support SHA256 hashes.
>>
>> There is inconvenience added here. You need to make a new email address,
>> you need to make a new github account to submit the BIP. I think it is
>> worth the cost -- but am interested in what others think about this. I
>> don't think people submitting patches to a BIP should be required to submit
>> under a pseudonym -- only the primary author. This means only one person
>> has to create the pseudonym. From a quick look at the BIPs list it looks
>> like the most BIPs submitted by one person is ~10. This means they would
>> have had to create 10 pseudonyms over 8 years -- I think this is
>> reasonable.
>>
>> *What does this give us?*
>>
>> This gives us a way to avoid politicization of BIPs. This means a BIP can
>> be proposed and examined based on it’s technical merits. This levels the
>> playing field — making the BIP process even more meritocratic than it
>> already is.
>>
>> If you want to claim credit for your BIP after it is accepted, you can
>> reveal the preimage of the author hash to prove that you were the original
>> author of the BIP. I would need to reveal my github username a

[bitcoin-dev] Requirement for pseudonymous BIP submissions

[Chris Stewart via bitcoin-dev]

As everyone in the Bitcoin space knows, there is a massive scaling debate
going on. One side wants to increase the block size via segwit, while the
other side wants to increase via hard fork. I have strong opinions on the
topic but I won’t discuss them here. The point of the matter is we are
seeing the politicization of protocol level changes. The critiques of these
changes are slowly moving towards critiques based on who is submitting the
BIP -- not what it actually contains. This is the worst thing that can
happen in a meritocracy.

*Avoiding politicization of technical changes in the future*

I like what Tom Elvis Judor did when he submitted his MimbleWimble white
paper to the technical community. He submitted it under a pseudonym, over
TOR, onto a public IRC channel. No ego involved — only an extremely
promising paper. Tom (and Satoshi) both understood that it is only a matter
of time before who they are impedes technical progress of their system.

I propose we move to a pseudonymous BIP system where it is required for the
author submit the BIP under a pseudonym. For instance, the format could be
something like this:

BIP: 1337

Author: 9458b7f9f76131f18823d73770e069d55beb2...@protonmail.com

BIP content down here

The hash “6f3…9cd0” is just my github username, christewart, concatenated
with some entropy, in this case these bytes:
639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b

and then hashed with RIPEMD160. I checked this morning that protonmail can
support RIPEMD160 hashes as email addresses. Unfortunately it appears it
cannot support SHA256 hashes.

There is inconvenience added here. You need to make a new email address,
you need to make a new github account to submit the BIP. I think it is
worth the cost -- but am interested in what others think about this. I
don't think people submitting patches to a BIP should be required to submit
under a pseudonym -- only the primary author. This means only one person
has to create the pseudonym. From a quick look at the BIPs list it looks
like the most BIPs submitted by one person is ~10. This means they would
have had to create 10 pseudonyms over 8 years -- I think this is
reasonable.

*What does this give us?*

This gives us a way to avoid politicization of BIPs. This means a BIP can
be proposed and examined based on it’s technical merits. This levels the
playing field — making the BIP process even more meritocratic than it
already is.

If you want to claim credit for your BIP after it is accepted, you can
reveal the preimage of the author hash to prove that you were the original
author of the BIP. I would need to reveal my github username and
“639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b”

*The Future*
Politicization of bitcoin is only going to grow in the future. We need to
make sure we maintain principled money instead devolving to a system where
our money is based on a democratic vote — or the votes of a select few
elites. We need to vet claims by “authority figures” whether it is Jihan
Wu, Adam Back, Roger Ver, or Greg Maxwell. I assure you they are human —
and prone to mistakes — just like the rest of us. This seems like a simple
way to level the playing field.

Thoughts?

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