npub1u0…dnn03

Last Notes

2023-06-09 12:56:17 UTC

- reply

📅 Original date posted:2019-10-01
📝 Original message:
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 at 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 script are compatible, e.g., the signature
> matches the public key specified in the output.
>
> BIP-118 is limited to explaining the details of signature verification, and
> omits anything related to deployment and dependency on other proposals.
> This
> was done in order not to depend on bip-taproot which is also in draft-phase
> currently, and to allow deployment alongside the next version of segwit
> script. `bip-anyprevout` builds on top of BIP-118, adding integration with
> `bip-taproot`, chaperone signatures, limits the use of the sighash flag to
> script path spends, as well as a new pubkey serialization which uses the
> first
> byte to signal opt-in.
>
> I'd like to stress that both proposals are complementary and not competing,
> which is something that I've heard a couple of times.
>
> There remain a couple of unclear points which I hope we can address in the
> coming days, to get this thing moving again, and hopefully get a new tool
> in
> our toolbox soon(ish).
>
> In the following I will quote a couple of things that were discussed during
> the CoreDev meeting earlier this year, but not everybody could join, and
> it is
> important that we engage the wider community, to get a better picture, and
> I
> think not everybody is up-to-date about the current state.
>
>
> ## Dangers of `sighash_noinput`
>
> An argument I have heard against noinput is that it is slightly less
> complex
> or compute intensive than `sighash_all` signatures, which may encourage
> wallet
> creators to only implement the noinput variant, and use it indiscrimi-
> nately. This is certainly a good argument, and indeed we have seen at least
> one developer proposing to use noinput for all transactions to discourage
> address reuse.
>
> This was also mentioned at CoreDev [6]:
>
> > When [...] said he wanted to write a wallet that only used
> SIGHASH\_NOINPUT,
> > that was pause for concern. Some people might want to use
> SIGHASH\_NOINPUT as a
> > way to cheapen or reduce the complexity of making a wallet
> > implementation. SIGHASH\_NOINPUT is from a purely procedural point of
> view
> > easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're
> hashing
> > less. It's way faster. That concern has been brought to my attention and
> it's
> > something I can see. Do we want to avoid people being stupid and shooting
> > themselves and their customers in the foot? Or do we treat this as a
> special
> > case where you mark we're aware of how it should be used and we just try
> to
> > get that awareness out?
>
> Another issue that is sometimes brought up is that an external user may
> attempt to send funds to a script that was really part of a higher-level
> protocol. This leads to those funds becoming inaccessible unless you gather
> all the participants and sign off on those funds. I don't believe this is
> anything new, and if users really want to shoot themselves in the foot and
> send funds to random addresses they fish out of a blockexplorer there's
> little
> we can do. What we could do is make the scripts used internally in our
> protocols unaddressable (see output tagging below), removing this issue
> altogether.
>
>
> ## Chaperone signatures
>
> Chaperone signatures are signatures that ensure that there is no
> third-party
> malleability of transactions. The idea is to have an additional signature,
> that doesn't use noinput, or any of its variants, and therefore needs to be
> authored by one of the pubkeys in the output script, i.e., one or more of
> the
> participants of the contract the transaction belongs to. Concretely in
> eltoo
> we'd be using a shared key known to all participants in the eltoo
> instance, so
> any participant can sign an update to rebind it to the desired output.
>
> Chaperone signatures have a number of downsides however:
>
> - Additional size: both the public key and the signature actually need
> to be
> stored along with the real noinput signature, resulting in transfer,
> computational and storage overhead. We can't reuse the same pubkey
> from the
> noinput signature since that'd require access to the matching privkey
> which
> is what we want to get rid of using noinput in the first place.
> - Protocols can still simply use a globally known privkey, voiding the
> benefit of chaperone signatures, since third-parties can sign again. I
> argue that third-party malleability is a subset of first-party
> malleability, and we should protect against first-party malleability
> first
> and foremost. My counterparty has the incentive to trick me, a
> third-party
> may not.
>
> On the plus side chaperone signatures certainly address the lazy-wallet-dev
> scenario, and as AJ points out in [bip-anyprevout] we get back the same
> security guarantees as we had without noinput.
>
> From what I remember and the transcript (thanks Kanzure for your awesome
> work
> by the way), there was no strong support for chaperone signatures during
> the
> meeting [6], but feedback from people that were not present is needed:
>
> > if everyone who wanted to use NOINPUT was convinced there was a problem,
> then
> > they would pick the right thing, but clearly people aren't. It's not a
> > foot-gun defense mechanism because it's easily bypassed, and it's easier
> to
> > bypass it than to use it. Whereas for tagged outputs, it's that if you
> want
> > any NOINPUT then you must tag.
>
>
> ## Output tagging
>
> One proposal that I found rather fascinating during the discussion in
> Amsterdam was that we could achieve the same disincentive to use on
> non-smart-contract cases by simply making the output scripts
> unaddressable. This can be done by specifying a version of taproot outputs
> for
> which the bech32 addressing scheme simply doesn't have a representation
> [6]:
>
> > The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT
> supported for
> > taproot v1 outputs, instead we have a segwit version 16 v16 that supports
> > taproot. The reason for v16 is that we redefine bech32 to not cover
> > v16. There's no addresses for this type of output. If you're an exchange
> and
> > receive a bech32 address, you declare it invalid. You make it less user
> > friendly here; and there shouldn't be an address anyway. You might want
> to see
> > it on a block explorer, but you don't want to pass it around to anyone.
>
> We don't need addresses in our contract constructions because we deal
> directly
> with the scripts. This would also have the desired effect of no allowing
> generic wallets to send to these addresses, or users accidentally sending
> funds to what was supposed to be a one-off script used internally in the
> off-chain contract.
>
> Notice that this idea was already used by Russell O'Connor when performing
> a
> transaction on elements using his new scripting language simplicity
> [7]:
>
> > For this experimental development, we created an improper segwit version,
> > "version 31" for Simplicity addresses. The payload of this segwit
> version 31
> > address contains a commitment Merkle root of a Simplicity program to
> control
> > the UTXO.
>
> The concern with output tagging is that it hurts fungibility, marking
> outputs
> used in a contract as such and making them identifiable. But maybe it
> would be
> a good idea to create two domains anyway: one for user-addressable
> destinations which users can use with their general purpose wallets, and
> one
> domain for contracts, which users cannot send to directly.
>
> This also came up during the CoreDev meeting [ams-coredev]:
>
> > these sort of NOINPUT signatures are only things that are within some
> > application or within some protocol that gets negotiated between
> participants,
> > but they don't cross-independent domains where you see a wallet or a
> protocol
> > as a kind of domain. You can't tell the difference, is this an address I
> can
> > give to someone else or not? It's all scripts, no real addresses. There
> are
> > types of outputs that are completely insecure unconditionally; there are
> > things that are protected and I can give to anyone, you don't want to
> reuse
> > it, but there's no security issue from doing so. This is an additional
> class
> > that is secure perfectly but only when used in the right way.
>
>
> ## Open questions
>
> The questions that remain to be addressed are the following:
>
> 1. General agreement on the usefulness of noinput / anyprevoutanyscript /
> anyprevout. While at the CoreDev meeting I think everybody agreed that
> these proposals a useful, also beyond eltoo, not everybody could be
> there. I'd therefore like to elicit some feedback from the wider
> community.
> 2. Is there strong support or opposition to the chaperone signatures
> introduced in anyprevout / anyprevoutanyscript? I think it'd be best to
> formulate a concrete set of pros and contras, rather than talk about
> abstract dangers or advantages.
> 3. The same for output tagging / explicit opt-in. What are the advantages
> and
> disadvantages?
> 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the
> confusion and make for simpler discussions in the end.
> 5. Anything I forgot to mention :-)
>
> Cheers,
> Christian
>
> [1] <
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.html
> >
> [2] <
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html
> >
> [3] <
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
> >
> [4] <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki>
> [5] <
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki
> >
> [6] <
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/
> >
> [7] <https://lists.ozlabs.org/pipermail/simplicity/2019/000018.html>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191001/6260f1ba/attachment-0001.html>

2023-06-09 12:55:23 UTC

- reply

📅 Original date posted:2019-07-04
📝 Original message:
Hey Alex,
I think the benefit here is in reducing the client-server interaction for
REST apis while still ensuring payment to the merchant.
Let's assume that we don't have this scheme, and want to provide a
monetized REST API. The workflow looks like this, which is similar to what
our behavior is now at Suredbits with websockets
<https://suredbits.com/ws-playground/>.
1. Client sends request to server for invoice
2. Server returns invoice
3. Client pays invoice
4. Server sends data back, or client makes request _again_ to a server and
then server returns data
With Nadav's scheme this is simplified to
1. Client sends request to server
2. Serves returns invoice, and encrypted payload
3. Client pays invoice
4. Client decrypts data according to Nadav's scheme
This saves a round trip between the server and client. It also gives
atomicity to the transaction, although as you stated before there is no
guarantees about integrity of the encrypted data. This is generally a hard
problem to solve in the technical sense, but I think the reputational harm
of the server sending bad data will be enough to prevent this, who wants to
do business with some one that isn't providing the advertised service? This
is a interaction that is could be repeated thousands of times on a daily
basis.
-Chris
On Thu, Jul 4, 2019 at 5:18 PM Alexander Leishman <leishman3 at gmail.com>
wrote:
> Nadav,
>
> This is an interesting proposal, but because this still requires the
> customer to trust the merchant, I am concerned that it adds complexity
> without any meaningful guarantee to the customer. Perhaps it makes sense to
> at least include some extension field here that allows the merchant to
> include a ZKP for ZKCP-compatible data transfers? However, there are a number
> of limitations <http://stevengoldfeder.com/papers/ZKCSP.pdf> to consider
> with those.
>
> My two cents, is that the proposed standard would only be useful for the
> edge case where a customer wants to pre-download the data before paying,
> but still trusts the merchant. What's the main use you see for that? My gut
> tells me there's a higher-level abstraction here to be standardized that
> would handle more mainstream use-cases.
>
> ZmnSCPxj,
>
> > Putting MAC inside the encryption would help ensure that we can detect
> data replacement over insecure channel, and use of shared secret ensures
> only intended recipient can decrypt.
>
> Generally you want to MAC the ciphertext + IV, otherwise you lose
> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>
> -Alex
>
>
> On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning Nadav et al.,
>>
>> > > Any node on the route of the payment knows the preimage and can
>> decrypt the data. It would be nice to tune the protocol in a way that only
>> the buyer can decrypt the data. For example we could use something like
>> this:
>> >
>> > Is this not covered by sending over the pre-image encrypted data over a
>> secure channel such as HTTPS? If anyone along the route who learns the
>> pre-image does intercept the message with the encrypted data, that data
>> will already be encrypted for the intended recipient right?
>>
>> True, but the added protection allows sending the option of sending data
>> over a non-secure channel.
>> In particular, a secure channel like HTTPS would impose an
>> encryption/decryption overhead, and then you will *also* encrypt/decrypt at
>> the application layer i.e. you are encrypting twice.
>> If you have the choice of using an insecure channel, you could take that
>> and only have the encrypt/decrypt overhead only for the preimage-encrypted
>> data.
>>
>> i.e. with this, you have the option of sending over both secure and
>> insecure channels.
>> It does not hinder use of secure channel, but enables use of insecure
>> channel.
>> Putting MAC inside the encryption would help ensure that we can detect
>> data replacement over insecure channel, and use of shared secret ensures
>> only intended recipient can decrypt.
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190704/f54ee691/attachment-0001.html>

2023-06-09 12:53:55 UTC

- reply

📅 Original date posted:2019-01-06
📝 Original message:
Hi all,
Hope your 2019 is off to a fantastic start. I'm really excited for
Lightning in 2019.
We are currently reviving a lite client project in bitcoin-s (
https://github.com/bitcoin-s/bitcoin-s-core/pull/280). The goal is to have
a modern replacement for bitcoinj that also can be used for L2 applications
like lightning. We also are planning on supporting multiple coins, hsms
etc.
The current plan is to implement traditional SPV, and then implement
neutrino when development is picking back up on that in bitcoin core. If
that takes too long, we will consider implementing neutrino against btcd.
What I wanted to ask of the mailing list is to give us "things to consider"
when developing this lite client from a usability perspective for lightning
devs. How can we make your lives easier?
One thing that seems logical is to adhere to the bitcoin core api when
possible, this means you can use bitcoin-s as a drop in lite client
replacement for bitcoin core.
Thoughts?
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190106/952809b3/attachment.html>

2023-06-07 23:05:09 UTC

- reply

📅 Original date posted:2022-03-05
📝 Original message: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 <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over just handing over `nLockTime`d transactions?
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220305/94c8f310/attachment.html>

2023-06-07 23:05:08 UTC

- reply

📅 Original date posted:2022-03-03
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220303/874d520f/attachment.html>

2023-06-07 18:05:19 UTC

- reply

📅 Original date posted:2017-09-05
📝 Original message: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
<https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/script/interpreter.cpp#L1420>
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
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-coins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60>.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.
-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170905/37b0bcbe/attachment.html>

2023-06-07 18:04:11 UTC

- reply

📅 Original date posted:2017-07-11
📝 Original message: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 at 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 (specifically Schnorr signatures), and has a number of
> benefits which
> are unrelated to capacity [4].
>
> Third, the Lightning Network, which allows users to transact without
> broadcasting to the network, is complete [5, 6] and awaits the
> activation of SegWit. For those users who are able to make a single
> on-chain transaction, it is estimated to increase both capacity and
> scalability by a factor of ~1000 (although these capacity increases will
> vary with usage patterns). LN also greatly improves transaction speed
> and transaction privacy.
>
> Fourth, Transaction Compression [7], observes that Bitcoin transaction
> serialization is not optimized for storage or network communication. If
> transactions were optimally compressed (as is possible today), this
> would improve scalability, but not capacity, by roughly 20%, and in some
> cases over 30%.
>
> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
> allowing many transactions to have a single shared signature, has been
> implemented [8] in draft form in libsecp256k1, and will likely be ready
> by Q4 of 2016. One analysis [9] suggests that signature aggregation
> would result in storage and bandwidth savings of at least 25%, which
> would therefore increase scalability and capacity by a factor of 1.33.
> The relative savings are even greater for multisignature transactions.
>
> Sixth, drivechain [10], which allows bitcoins to be temporarily
> offloaded to 'alternative' blockchain networks ("sidechains"), is
> currently under peer review and may be usable by end of 2017. Although
> it has no impact on scalability, it does allow users to opt-in to
> greater capacity, by moving their BTC to a new network (although, they
> will achieve less decentralization as a result). Individual drivechains
> may have different security tradeoffs (for example, a greater reliance
> on UTXO commitments, or MimbleWimble's shrinking block history) which
> may give them individually greater scalability than mainchain Bitcoin.
>
> Finally, the capacity improvements outlined above may not be sufficient.
> If so, it may be necessary to use a hard fork to increase the blocksize
> (and blockweight, sigops, etc) by a moderate amount. Such an increase
> should take advantage of the existing research on hard forks, which is
> substantial [11]. Specifically, there is some consensus that Spoonnet
> [12] is the most attractive option for such a hardfork. There is
> currently no consensus on a hard fork date, but there is a rough
> consensus that one would require at least 6 months to coordinate
> effectively, which would place it in the year 2018 at earliest.
>
> The above are only a small sample of current scaling technologies. And
> even an exhaustive list of scaling technologies, would itself only be a
> small sample of total Bitcoin innovation (which is proceeding at
> breakneck speed).
>
> Signed,
> <Names Here>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-December/011865.html
> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
> [5]
> http://lightning.community/release/software/lnd/
> lightning/2017/05/03/litening/
> [6] https://github.com/ACINQ/eclair
> [7] https://people.xiph.org/~greg/compacted_txn.txt
> [8]
> https://github.com/ElementsProject/secp256k1-zkp/blob/
> d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
> [10] http://www.drivechain.info/
> [11] https://bitcoinhardforkresearch.github.io/
> [12]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-February/013542.html
>
> ==== End of Roadmap Draft ====
>
> In short, please let me know:
>
> 1. If you agree that it would be helpful if the roadmap were updated.
> 2. To what extent, if any, you like this draft.
> 3. Edits you would make (specifically, I wonder about Drivechain
> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
> Fork date).
>
> Google Doc (if you're into that kind of thing):
> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNoc
> mCq-jjBOQSVH-A/edit?usp=sharing
>
> Cheers,
> Paul
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/8b9806dd/attachment-0001.html>

2023-06-07 18:03:44 UTC

- reply

📅 Original date posted:2017-06-30
📝 Original message:>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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170630/fdacfffe/attachment-0001.html>

2023-06-07 18:03:39 UTC

- reply

📅 Original date posted:2017-06-27
📝 Original message:<pre>
BIP: <BIP number>
Layer: Consensus (Soft fork)
Title: OP_BRIBEVERIFY
Author: Chris Stewart <chris at suredbits.com>
Status: Draft
Type: Standards Track
Created: 2017-06-27
</pre>
==Abstract==
This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
scripting system that allows for a user to bribe a miner to include a hash
in the coinbase transaction's output.
==Summary==
BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given
critical hash is included at the given vout index in the coinbase
transaction
the script evaluates to true. Otherwise, the script will fail.
This allows sidechains to be merged mined against
bitcoin without burdening bitcoin miners with extra resource requirements.
==Motivation==
The current political climate of bitcoin is extremely contentious. Many
community members
have different visions of what bitcoin is. This op code is meant to
enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge
Mining].
This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners
can
bribe bitcoin miners to to include their block hash in the bitcoin
blockchain. If their block
is included in the coinbase transaction's vout, it is assumed that block is
a mined block on the sidechain.
This will allow various factions of the community to realize their vision
on their own separate
blockchain that is interoperable with the bitcoin blockchain. This allows
those factions to use
bitcoin as a 'reserve currency' for their own network.
===Commitment Structure===
A new block rule is added which requires that the miner's coinbase reward
be at index 0 in the coinbase transaction's output vector.
It also fixes the witness commitment output to be at index 1 of the
coinbase transaction's output vector.
This is needed so we can reliably tell what vout corresponds to what
drivechain. For instance, the mimblewimble sidechain
could correspond to index 2 of the vector outputs on the coinbase
transaction.
The commitment is recorded in a <code>scriptPubKey</code> of the coinbase
transaction. It must be at least 34 bytes in size
1-byte - OP_RETURN (0x6a)
1-byte - Push the following 32 bytes (0x20)
32-byte - block hash
the 35th byte and onward have no consensus meaning.
===OP_BRIBEVERIFY op code===
This op code reads two arguments from the stack. The stack top is expected
to be a sidechain id for which this user attempting to blind merge mine for.
The next element on the stack is expected to be a block hash. This op code
looks into the coinbase transaction's output vector at the given index
(which is derived from the sidechain id) and checks
to see if the hash in the block matches the hash inside of the BRIBEVERIFY
program. If the hashes match, the OP_BRIBEVERIFY acts as an OP_NOP. If the
comparison between the two hashes fail, the script fails.
===BRIBEVERIFY program===
A standard BRIBEVERIFY program has the format:
1-byte - Push the following 32 bytes (0x20)
32-byte - block hash
1 byte - Push operation? (needed if number can't be encoded as OP_0 -
OP_16)
1 byte - sidechain id
1 byte - OP_BRIBEVERIFY op code
==Detailed Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP4:
{
//format: block_hash sidechain_id OP_BRIBEVERIFY
if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
// not enabled; treat as a NOP4
if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}
if (stack.size() < 2)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);
uint8_t nSidechainId;
if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {
return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
}
// Check block hash
bool fHashCritical =
checker.CheckCriticalHash(stacktop(-2),nSidechainId);
if (!fHashCritical) {
return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
}
break;
}
https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
https://github.com/drivechain-project/bitcoin/pull/13
==Deployment==
TODO
==Credits==
Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.
Credit to CryptAxe for writing the foundational layer of software for
drivechains so I could implement OP_BRIBEVERIFY.
==References==
Blind Merge Mined Sidechains -
http://www.truthcoin.info/blog/blind-merged-mining/
Mailing list discussion -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014408.html
==Copyright==
This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/bd5730bf/attachment.html>

2023-06-07 18:00:03 UTC

- reply

📅 Original date posted:2017-04-14
📝 Original message:>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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/065e4fee/attachment.html>

2023-06-07 17:57:20 UTC

- reply

📅 Original date posted:2017-03-18
📝 Original message: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: 9458b7f9f76131f18823d73770e069d55beb271b at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170318/c788f5e3/attachment.html>

2023-06-07 17:57:20 UTC

- reply

📅 Original date posted:2017-03-18
📝 Original message:>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 <person I've been annoyed by in the past> 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.johnson83 at 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 <person I've been annoyed by in the past> 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 at 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: 9458b7f9f76131f18823d73770e069d55beb271b at 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 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170318/610a02b7/attachment-0001.html>