Nostr notes by

📅 Original date posted:2023-05-08 🗒️ Summary of this ...

2023-06-19T17:42:04Z

In reply to nevent1q…280g
_________________________

📅 Original date posted:2023-05-08
🗒️ Summary of this message: The Lightning-dev mailing list is experiencing delays due to a lack of moderators, prompting discussions about finding a better platform for public communication.
📝 Original message:
Well, you could always send to bitcoin-dev at lists.linuxfoundation.org -- we
are usually pretty fast with email modqueue.

On Mon, May 8, 2023 at 3:26 PM Tony Giorgio via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Is there a better place to have public communication? Unfortunately since
> one off topic email was sent here, it's been a ghost town. It appears that
> there's many emails being held and only one moderator that checks them once
> a week.
>
> Would hate to see this list die but wondering if there's a better place
> for discussions?
>
> Tony
>
>
>
>
>
>
> -------- Original Message --------
> On Apr 29, 2023, 9:57 PM, niftynei < niftynei at gmail.com> wrote:
>
>
> Hi all,
>
> When I joined the lightning community a few years ago, I was relatively
> new to open source software and specification work. Rusty really impressed
> on me on the importance of holding conversations, as much as possible in
> public.
>
> Practically speaking, this encompasses IRC, this mailing list, and github
> issues/PRs.
>
> The reason for this is twofold. It helps document the range of options
> considered for technical decisions and it provides an interface point for
> new participants to contribute to the discussion.
>
> Given some recent mails that were posted to this list, now seems like a
> good time to reiterate the importance and preference of public
> communication whenever possible, especially for specification or technical
> discussions.
>
>
> ~ nifty
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>

--
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230508/bae066c7/attachment-0001.html>;

📅 Original date posted:2023-05-08 🗒️ Summary of this ...

2023-06-07T23:21:18Z

In reply to nevent1q…p7v2
_________________________

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A discussion on the governance of Bitcoin Core, a volunteer project of independent contributors merging different pull requests or patches.
📝 Original message:On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>

Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
independent contributors merging different pull requests or patches. The
github controls are merely because that is how github works. There is also
a secondary issue of people tending to confuse Bitcoin Core with the
bitcoin protocol in general:
https://blog.lopp.net/who-controls-bitcoin-core/
https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427

- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/bb17ae25/attachment.html>;

📅 Original date posted:2022-10-17 📝 Original message:On ...

2023-06-07T23:14:05Z

In reply to nevent1q…gw5l
_________________________

📅 Original date posted:2022-10-17
📝 Original message:On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Unbeknownst to them, the clipboard contents have been replaced with an
> address controlled by some bad actor.
>
[snip]

> Now imagine instead that the wallet has some address book with a pubkey
> for each recipient the user wants to send bitcoin to.
>

Isn't this the same problem but now for copy-pasting pubkeys instead of an
address?

- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/b48635dc/attachment.html>;

📅 Original date posted:2022-06-14 📝 Original message:On ...

2023-06-07T23:10:41Z

In reply to nevent1q…vrsa
_________________________

📅 Original date posted:2022-06-14
📝 Original message:On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of
Many via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.

Publication is not a component of the OTS system.

This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
>

(Why would it be needless to require everyone to publish OTS files but not
needless to require everyone to publish via OP_RETURN? In fact, now you
have blockchain users that don't ever use your OP_RETURN data.)

> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
>

You can't replace a timestamp in the OTS system; you can only make a new
timestamp. To use the earlier timestamp, you would have to use the earlier
timestamp. At any time it is allowed to make a new timestamp based on the
current clock. The use case for OTS is proving document existence as of a
certain time and that if you had doctored a file then said doctoring was no
later than the earliest timestamp that can be provided.

I was just talking about this the other day actually...
https://news.ycombinator.com/item?id=31640752

- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/16da0bbc/attachment.html>;

📅 Original date posted:2022-04-26 📝 Original message:You ...

2023-06-07T23:08:21Z

In reply to nevent1q…mmq0
_________________________

📅 Original date posted:2022-04-26
📝 Original message:You may be interested in these posts on transaction signalling:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html

On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of ____ if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17 miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it such that users could more directly
> pressure miners to act on their behalf? After all, if miners are but the
> humble servants of user demands, this should be in alignment with how
> people want Bitcoin to behave.
>
> Currently, the only means users have of influencing miner decisions are A.
> rejection of blocks that don't follow rules and B. paying fees for
> transaction inclusion. I suggest we combine these in such a way that
> transactions themselves can signal for upgrade. I believe (though am not
> certain) that there are "free" bits in the version field of a transaction
> that are presently ignored. If we could devise a mapping between some of
> those free bits, and the signaling bits in the block header, it would be
> possible to have rules as follows:
>
> - A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
> - A transaction that is NOT signaling MAY be included in a block
> regardless of that block's signaling vector
> - (Optional) A transaction signaling in the negative MUST NOT be included
> in a block that signals in the affirmative
>
> Under this set of conditions, a user has the means of sybil-resistant
> influence over miner decisions. If a miner cannot collect the fees for a
> transaction without signaling, the user's fee becomes active economic
> pressure for the miner to signal (or not, if we include some variant of the
> negative clause). In this environment, miners could have a better view into
> what users do want, as would the Bitcoin network at large.
>
> Some may take issue with the idea that people can pay for the outcome they
> want and may try to compare a method like this to Proof of Stake, but there
> are only 3 sybil resistant mechanisms I am aware of, and any "real" view
> into what social consensus looks like MUST be sybil resistant:
>
> - Hashpower
> - Proof of personhood (KYC)
> - Capital burn/risk
>
> Letting hashpower decide this is the thing that is currently contentious,
> KYC is dead on arrival both on technical and social grounds, which really
> just leaves some means of getting capital into the process of consensus
> measurement. This mechanism I'm proposing is measurable completely
> en-protocol and doesn't require trust in institutions that fork futures
> would. Additionally it could be an auxiliary feature of the soft fork
> deployment scheme chosen making it something you could neatly package all
> together with the deployment itself.
>
> There are many potential tweaks to the design I propose above:
> 1. Do we include a notion of negative signaling (allowing for the
> possibility of rejection)
> 2. Do we make it such that miner signaling must be congruent with >X% of
> transactions, where congruence is that the signal must match any
> non-neutral signal of transaction.
>
> Some anticipated objections:
>
> 1. signaling isn't voting, no deployment should be made without consensus
> first.
> - yeah well we can't currently measure consensus right now, so that's not
> a super helpful thing to say and is breeding ground for abuse in the form
> of certain people making the unsubstantiated claim that consensus does or
> does not exist for a particular initiative
>
> 2. This is just a proposal for "pay to play", we should not let the
> wealthy make consensus decisions.
> - I agree that wealth should not be able to strong-arm decision making.
> But the status quo seems even worse where we let publicly influential
> people decide consensus in such a way where not only do they not "lose
> ammunition" in the process of campaigning, but actually accrue it, creating
> really bad long-term balances of power.
>
> 3. Enforcing this proposal requires its own soft fork.
> - Yes. It does...and there's a certain cosmic irony to that, but before we
> consider how to make this happen, I'd like to even discuss whether or not
> it's a good idea.
>
> 4. This gives CoinJoin pool operators and L2 protocol implementations
> power over deciding consensus.
> - I see this as an improvement over the status quo
>
> 5. This encourages "spam"
> - If you pay the fees, it's not spam.
>
> The biggest question I'd like to pose to the forum is:
> - Does a scheme like this afford us a better view into consensus than we
> have today?
> - Can it be gamed to give us a *worse* view into consensus? How?
> - Does it measure the right thing? If not, what do you think is the right
> thing to measure? (assuming we could)
> - Should I write a BIP spec'ing this out in detail?
>
> Cheers,
> Keagan
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/64c2013e/attachment.html>;

📅 Original date posted:2019-08-12 📝 Original message:On ...

2023-06-07T18:20:08Z

In reply to nevent1q…g2qg
_________________________

📅 Original date posted:2019-08-12
📝 Original message:On Mon, Aug 12, 2019 at 10:01 AM Peter Todd <pete at petertodd.org> wrote:

> The key difference being it's not important that this be a *public*
> notification: that the public can see just happens to be an (unfortunate)
> implementation detail. For example, you could imagine a system where the
> "prepare to spend" tx is indistinguishable from any other transaction.
>

True, I did not intend for everyone to know the meaning of the observed
transaction. It turns out to not be too useful to the scheme anyway, unless
you're interested in protecting against an adversary dumb enough to tell
you he has stolen your key before spending your coins. To reiterate my
other follow-up email, the best you can do (... or the best I can do right
now) is limit losses to k% where k is selected by the user, e.g. 1 input
100 outputs each with succesively increasing timeouts allowing the rotten
non-rotated(pre-inserted) key to spend, and instant spending by a recovery
flow. Once the attacker steals any one of the k% outputs, you know to not
let the outputs timeout to that key in the future. Unfortunately, without
an opcode-style covenant, the only way to know if a stale hot key is stolen
is to observe an unexpected spend or, if you're lucky, observe an
unexpected signature otherwise unassociated with a transaction.

> > * Nuclear abort key: Also unnecessary. This is a key for which only a
> single

>
Obviously normally to provably destroy coins you'd spend to an OP_RETURN
> output, or if miner censorship was an issue, a pay-to-script-hash of an
> OP_RETURN <nonce> script.
>

Oh, right. Well, that works.

> > Delete the key (for pre-signed transactions)
> > ============================================
> >
> > The delete-the-key trick is simple. The idea is to pre-sign at least one
> > transaction and then delete the private key, thus locking in that course
> of
> > action.
> >
> > Unfortunately, delete-the-key doesn't really work for multisig scenarios
> > because nobody would trust that anyone else in the scheme has actually
> deleted
> > the secret. If they haven't deleted the secret, then they have full
> unilateral
> > control to sign anything in that branch of the transaction tree. The
> only time
> > that delete-the-key might be appropriate would be where the user who
> deletes
> > the key and controls the key during the setup process is also the sole
> > beneficiary of the entire setup with the multisig participants.
> >
> > Alternative fee rates are easier to deal with using delete-the-key,
> compared to
> > a technique where the private key never existed which can only be used
> to sign
> > one fee rate per public key, requiring an entirely new vault subtree for
> each
> > alternative fee rate. With delete-the-key, the alternative fee rates are
> signed
> > with the private key before the private key is deleted.
>
> I think this could use a bit more analysis here: why can't delete the
> *keys*
> work, with each party deleting a separate private key that's used in an
> m-of-n
> fashion? So long as at least n-m+1 parties actually deleted their keys
> IIUC it
> should be secure.
>

I was thinking about another construction where you pick a key as a group
(separate from the multisig setup) and sign with that. But in practice, as
you have pointed out, you would do the delete-the-key trick on the multisig
construction itself with each party contributing their own pubkey,
requiring 1/n honest deletes.

> > Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> > =================================================================
> >
> > A group can participate in a multisig scheme with provably-unknown ECDSA
> keys.
> > Instead of deleting the key, the idea is to agree on a blockheight and
> then
> > select the blockhash (or some function of the chosen blockhash like
> > H(H(H(blockhash)))) as the signature. Next, the group agrees on a
> transaction
> > and they recover the public key from the signature using ECDSA pubkey
> recovery.
>
> Could you explain in more detail why you're deriving this from a blockhash?
>

Well you need to pick an entropy source, and I wouldn't want to tell people
to just trust the first party to tell you a good sequence of bytes.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190812/457a9f30/attachment-0001.html>;

📅 Original date posted:2019-08-07 📝 Original ...

2023-06-07T18:20:07Z

In reply to nevent1q…90k0
_________________________

📅 Original date posted:2019-08-07
📝 Original message:Replying to two emails below.

On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> > - Re-vaulting transaction. This is where the magic happens. The
> re-vaulting
> > transaction is signed during transaction tree setup, before
> constructing the
> > delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> > broadcasted when someone wants to prevent a coin withdrawal during
> the public
> > observation delay period. The re-vaulting transaction spends the
> delayed-spend
> > transaction outputs. It has a single output with a script created by
> running
> > the entire vault setup function again. Hence, when the re-vaulting
> transaction
> > is confirmed, all of the coins go back into a new
> identically-configured vault
> > instead of being relinquished through the delayed-spend transaction
> timeout for
> > hot wallet key signing.
>
> As transactions need to be signed in reverse order, it seems to me that
> there is a practical limit in the number of times a vault can be used.
> Basically, the number of times we run the vault setup function is the
> limit on number of re-vaultings possible.
>
> Is my understanding correct?
>

Yes, that is correct. When setting up the vault, plan it "all the way to
the end" like next 100+ years. With exponential backoff on the relative
timelock values, the total number of pre-signed transactions isn't really
that high. With a few thousand pre-signed transactions (more than enough),
you can have high resolution timelocks well into the future.

On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer <dustinpaystaxes at gmail.com>
wrote:

> Does revaulting vault up with the same keys, or new ones?
> Are they new derivation paths on the same key?
>

Honestly, no idea. The answer to that might depend on each individual vault
user. If the user doesn't want to deal with the expense of managing a bunch
of unique keys and other data, then it might make more sense to use the
same values and have a small blob that has to be stored for a long time,
rather than many different blobs stored in different places to deal with.

- Bryan
http://heybryan.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190807/8b220b88/attachment.html>;

📅 Original date posted:2019-08-07 📝 Original message:Hi, ...

2023-06-07T18:20:06Z

In reply to nevent1q…v5hc
_________________________

📅 Original date posted:2019-08-07
📝 Original message:Hi,

One of the biggest problems with the vault scheme (besides all of the
setup data that has to be stored for a long time) is an attacker that
silently steals the hot wallet private key and waits for the vault's
owner to make a delayed-spend transaction to initiate a withdrawal
from the vault. If the user was unaware of the theft of the key, then
the attacker could steal the funds after the delay period.

To mitigate this, it is important to choose a stipend or withdrawal
amount per withdrawal period like x% of the funds. This limits the
total stolen funds to x% because once the funds are stolen the user
would know their hot key is compromised, and the user would know to
instead use one of the other clawback paths during all of the future
withdrawal delay periods instead of letting the delay timeout all the
way to the (stolen) default/hot key.

The reason why a loss limiter is the way to go is because there's
currently no way (that I am aware of, without an upgrade) to force an
attacker to reveal his key on the blockchain while also forcing the
attacker to use a timelock before the key can spend the coins. I am
curious about what the smallest least invasive soft-fork would be for
enabling this kind of timelock. There are so many covenant proposals
at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
....). Or there's crazy things like a fork that enables a transaction
mode where the (timelock...) script of the first output is
automatically prefixed to any of the other scripts on any of the other
outputs when an input tries to spend in the future. A thief could add
his key to a new output on the transaction and try to spend (just like
a user would with a fresh/rotated key), but the OP_CSV would be
automatically added to his script to implement the public observation
delay window.

Also, there was other previous work that I was only informed about
today after posting my proposal, so I should mention these as related
work:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
https://www.youtube.com/watch?v=diNxp3ZTquo
https://bitcointalk.org/index.php?topic=5111656

- Bryan
http://heybryan.org/

📅 Original date posted:2019-06-07 📝 Original message:Hi, ...

2023-06-07T18:18:38Z

📅 Original date posted:2018-02-08 📝 Original ...

2023-06-07T18:10:34Z

In reply to nevent1q…0306
_________________________

📅 Original date posted:2018-02-08
📝 Original message:---------- Forwarded message ----------
From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Date: Mon, Feb 5, 2018 at 11:26 PM
Subject: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning
To: lightning-dev <lightning-dev at lists.linuxfoundation.org>

Hi Y'all,

A common question I've seen concerning Lightning is: "I have five $2
channels, is it possible for me to *atomically* send $6 to fulfill a
payment?". The answer to this question is "yes", provided that the receiver
waits to pull all HTLC's until the sum matches their invoice. Typically, one
assumes that the receiver will supply a payment hash, and the sender will
re-use the payment hash for all streams. This has the downside of payment
hash re-use across *multiple* payments (which can already easily be
correlated), and also has a failure mode where if the sender fails to
actually satisfy all the payment flows, then the receiver can still just
pull the monies (and possibly not disperse a service, or w/e).

Conner Fromknecht and I have come up with a way to achieve this over
Lightning while (1) not re-using any payment hashes across all payment
flows, and (2) adding a *strong* guarantee that the receiver won't be paid
until *all* partial payment flows are extended. We call this scheme AMP
(Atomic Multi-path Payments). It can be experimented with on Lightning
*today* with the addition of a new feature bit to gate this new
feature. The beauty of the scheme is that it requires no fundamental changes
to the protocol as is now, as the negotiation is strictly *end-to-end*
between sender and receiver.

TL;DR: we repurpose some unused space in the onion per-hop payload of the
onion blob to signal our protocol (and deliver some protocol-specific data),
then use additive secret sharing to ensure that the receiver can't pull the
payment until they have enough shares to reconstruct the original pre-image.

Protocol Goals
==============
1. Atomicity: The logical transaction should either succeed or fail in
entirety. Naturally, this implies that the receiver should not be unable to
settle *any* of the partial payments, until all of them have arrived.

2. Avoid Payment Hash Reuse: The payment preimages validated by the
consensus layer should be distinct for each partial payment. Primarily,
this helps avoid correlation of the partial payments, and ensures that
malicious intermediaries straddling partial payments cannot steal funds.

3. Order Invariance: The protocol should be forgiving to the order in which
partial payments arrive at the destination, adding robustness in the face of
delays or routing failures.

4. Non-interactive Setup: It should be possible for the sender to perform an
AMP without directly coordinating with the receiving node. Predominantly,
this means that the *sender* is able to determine the number of partial
payments to use for a particular AMP, which makes sense since they will be
the one fronting the fees for the cost of this parameter. Plus, we can
always turn a non-interactive protocol into an interactive one for the
purposes of invoicing.

Protocol Benefits
=================

Sending pay payments predominantly over an AMP-like protocol has several
clear benefits:

- Eliminates the constraint that a single path from sender to receiver
with sufficient directional capacity. This reduces the pressure to have
larger channels in order to support larger payment flows. As a result,
the payment graph be very diffused, without sacrificing payment
utility

- Reduces strain from larger payments on individual paths, and allows the
liquidity imbalances to be more diffuse. We expect this to have a
non-negligible impact on channel longevity. This is due to the fact that
with usage of AMP, payment flows are typically *smaller* meaning that
each payment will unbalance a channel to a lesser degree that
with one giant flow.

- Potential fee savings for larger payments, contingent on there being a
super-linear component to routed fees. It's possible that with
modifications to the fee schedule, it's actually *cheaper* to send
payments over multiple flows rather than one giant flow.

- Allows for logical payments larger than the current maximum value of an
individual payment. Atm we have a (temporarily) limit on the max payment
size. With AMP, this can be side stepped as each flow can be up the max
size, with the sum of all flows exceeding the max.

- Given sufficient path diversity, AMPs may improve the privacy of LN
Intermediaries are now unaware to how much of the total payment they are
forwarding, or even if they are forwarding a partial payment at all.

- Using smaller payments increases the set of possible paths a partial
payment could have taken, which reduces the effectiveness of static
analysis techniques involving channel capacities and the plaintext
values being forwarded.

Protocol Overview
==================
This design can be seen as a generalization of the single, non-interactive
payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
extra data for the receiver. In that design, the extra data includes a
payment preimage that the receiver can use to settle back the payment. EOBs
and some method of parsing them are really the only requirement for this
protocol to work. Thus, only the sender and receiver need to implement this
feature in order for it to function, which can be announced using a feature
bit.

First, let's review the current format of the per-hop payload for each node
described in BOLT-0004.

┌───────────────┬───────────────────┬────────────────┬──────
─────────────────┬─────────────────┬─────────────────┐
│Realm (1 byte) │Next Addr (8 bytes)│Amount (8 bytes)│Outgoing CLTV (4
bytes)│Unused (12 bytes)│ HMAC (32 bytes) │
└───────────────┴───────────────────┴────────────────┴──────
─────────────────┴─────────────────┴─────────────────┘
■───────────────────────────────────────────────────────────
─────────────────────────────────────────────────────■
┌─────────────────┐
│65 Bytes Per Hop │
└─────────────────┘

Currently, *each* node gets a 65-byte payload. We use this payload to give
each node instructions on *how* to forward a payment. We tell each node: the
realm (or chain to forward on), then next node to forward to, the amount to
forward (this is where fees are extracted by forwarding out less than in),
the outgoing CLTV (allows verification that the prior node didn't modify any
values), and finally an HMAC over the entire thing.

Two important points:
1. We have 12 bytes for each hop that are currently unpurposed and can be
used by application protocols to signal new interpretation of bytes and
also deliver additional encrypted+authenticated data to *each* hop.

2. The protocol currently has a hard limit of 20-hops. With this feature
we ensure that the packet stays fixed sized during processing in order to
avoid leaking positional information. Typically most payments won't use
all 20 hops, as a result, we can use the remaining hops to stuff in *even
more* data.

Protocol Description
====================
The solution we propose is Atomic Multi-path Payments (AMPs). At a high
level, this leverages EOBs to deliver additive shares of a base preimage,
from which the payment preimages of partial payments can be derived. The
receiver can only construct this value after having received all of the
partial payments, satisfying the atomicity constraint.

The basic protocol:

Primitives
==========
Let H be a CRH function.
Let || denote concatenation.
Let ^ denote xor.

Sender Requirements
===================
The parameters to the sending procedure are a random identifier ID, the
number of partial payments n, and the total payment value V. Assume the
sender has some way of dividing V such that V = v_1 + … + v_n.

To begin, the sender builds the base preimage BP, from which n partial
preimages will be derived. Next, the sender samples n additive shares s_1,
…, s_n, and takes the sum to compute BP = s_1 ^ … ^ s_n.

With the base preimage created, the sender now moves on to constructing the
n partial payments. For each i in [1,n], the sender deterministically
computes the partial preimage r_i = H(BP || i), by concatenating the
sequence number i to the base preimage and hashing the result. Afterwards,
it applies H to determine the payment hash to use in the i’th partial
payment as h_i = H(r_i). Note that that with this preimage derivation
scheme, once the payments are pulled each pre-image is distinct and
indistinguishable from any other.

With all of the pieces in place, the sender initiates the i’th payment by
constructing a route to the destination with value v_i and payment hash h_i.
The tuple (ID, n, s_i) is included in the EOB to be opened by the receiver.

In order to include the three tuple within the per-hop payload for the final
destination, we repurpose the _first_ byte of the un-used padding bytes in
the payload to signal version 0x01 of the AMP protocol (note this is a PoC
outline, we would need to standardize signalling of these 12 bytes to
support other protocols). Typically this byte isn't set, so the existence of
this means that we're (1) using AMP, and (2) the receiver should consume the
_next_ hop as well. So if the payment length is actually 5, the sender tacks
on an additional dummy 6th hop, encrypted with the _same_ shared secret for
that hop to deliver the e2e encrypted data.

Note, the sender can retry partial payments just as they would normal
payments, since they are order invariant, and would be indistinguishable
from regular payments to intermediaries in the network.

Receiver Requirements
=====================

Upon the arrival of each partial payment, the receiver will iteratively
reconstruct BP, and do some bookkeeping to figure out when to settle the
partial payments. During this reconstruction process, the receiver does not
need to be aware of the order in which the payments were sent, and in fact
nothing about the incoming partial payments reveals this information to the
receiver, though this can be learned after reconstructing BP.

Each EOB is decoded to retrieve (ID, n, s_i), where i is the unique but
unknown index of the incoming partial payment. The receiver has access to
persistent key-value store DB that maps ID to (n, c*, BP*), where c*
represents the number of partial payments received, BP* is the sum of the
received additive shares, and the superscript * denotes that the value is
being updated iteratively. c* and BP* both have initial values of 0.

In the basic protocol, the receiver cache’s the first n it sees, and
verifies that all incoming partial payments have the same n. The receiver
should reject all partial payments if any EOB deviates. Next, the we update
our persistent store with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing the
reconstruction by one step.

If c* + 1 < n, there are still more packets in flight, so we sit tight.
Otherwise, the receiver assumes all partial payments have arrived, and can
being settling them back. Using the base preimage BP = BP* ^ s_i from our
final iteration, the receiver can re-derive all n partial preimages and
payment hashes, using r_i = H(BP || i) and h_i = H(r_i) simply through
knowledge of n and BP.

Finally, the receiver settles back any outstanding payments that include
payment hash h_i using the partial preimage r_i. Each r_i will appear random
due to the nature of H, as will it’s corresponding h_i. Thus, each partial
payment should appear uncorrelated, and does not reveal that it is part of
an AMP nor the number of partial payments used.

Non-interactive to Interactive AMPs
===================================

Sender simply receives an ID and amount from the receiver in an invoice
before initiating the protocol. The receiver should only consider the
invoice settled if the total amount received in partial payments containing
ID matches or exceeds the amount specified in the invoice. With this
variant, the receiver is able to map all partial payments to a pre-generated
invoice statement.

Additive Shares vs Threshold-Shares
===================================

The biggest reason to use additive shares seems to be atomicity. Threshold
shares open the door to some partial payments being settled, even if others
are left in flight. Haven’t yet come up with a good reason for using
threshold schemes, but there seem to be plenty against it.

Reconstruction of additive shares can be done iteratively, and is win for
the storage and computation requirements on the receiving end. If the sender
decides to use fewer than n partial payments, the remaining shares could be
included in the EOB of the final partial payment to allow the sender to
reconstruct sooner. Sender could also optimistically do partial
reconstruction on this last aggregate value.

Adaptive AMPs
=============

The sender may not always be aware of how many partial payments they wish to
send at the time of the first partial payment, at which point the simplified
protocol would require n to be chosen. To accommodate, the above scheme can
be adapted to handle a dynamically chosen n by iteratively constructing the
shared secrets as follows.

Starting with a base preimage BP, the key trick is that the sender remember
the difference between the base preimage and the sum of all partial
preimages used so far. The relation is described using the following
equations:

X_0 = 0
X_i = X_{i-1} ^ s_i
X_n = BP ^ X_{n-1}

where if n=1, X_1 = BP, implying that this is in fact a generalization of
the single, non-interactive payment scheme mentioned above. For i=1, ...,
n-1, the sender sends s_i in the EOB, and X_n for the n-th share.

Iteratively reconstructing s_1 ^ …. ^ s_{n-1} ^ X_n = BP, allows the
receiver to compute all relevant r_i = H(BP || i) and h_i = H(r_i). Lastly,
the final number of partial payments n could be signaled in the final EOB,
which would also serve as a sentinel value for signaling completion. In
response to DOS vectors stemming from unknown values of n, implementations
could consider advertising a maximum value for n, or adopting some sort of
framing pattern for conveying that more partial payments are on the way.

We can further modify our usage of the per-hop payloads to send (H(BP),
s_i) to
consume most of the EOB sent from sender to receiver. In this scenario, we'd
repurpose the 11-bytes *after* our signalling byte in the unused byte
section
to store the payment ID (which should be unique for each payment). In the
case
of a non-interactive payment, this will be unused. While for interactive
payments, this will be the ID within the invoice. To deliver this slimmer
2-tuple, we'll use 32-bytes for the hash of the BP, and 32-bytes for the
partial pre-image share, leaving an un-used byte in the payload.

Cross-Chain AMPs
================

AMPs can be used to pay a receiver in multiple currencies atomically...which
is pretty cool :D

Open Research Questions
=======================

The above is a protocol sketch to achieve atomic multi-path payments over
Lightning. The details concerning onion blob usage serves as a template that
future protocols can draw upon in order to deliver additional data to *any*
hop in the route. However, there are still a few open questions before
something like this can be feasibly deployed.

1. How does the sender decide how many chunked payments to send, and the
size of each payment?

- Upon a closer examination, this seems to overlap with the task of
congestion control within TCP. The sender may be able to utilize
inspired heuristics to gauge: (1) how large the initial payment should
be
and (2) how many subsequent payments may be required. Note that if the
first payment succeeds, then the exchange is over in a signal round.

2. How can AMP and HORNET be composed?

- If we eventually integrate HORNET, then a distinct communications
sessions can be established to allow the sender+receiver to exchange
up-to-date partial payment information. This may allow the sender to
more
accurately size each partial payment.

3. Can the sender's initial strategy be governed by an instance of the
Push-relabel max flow algo?

4. How does this mesh with the current max HTLC limit on a commitment?

- ATM, we have a max limit on the number of active HTLC's on a particular
commitment transaction. We do this, as otherwise it's possible that the
transaction is too large, and exceeds standardness w.r.t transaction
size. In a world where most payments use an AMP-like protocol, then
overall ant any given instance there will be several pending HTLC's on
commitments network wise.

This may incentivize nodes to open more channels in order to support
the increased commitment space utilization.

Conclusion
==========

We've presented a design outline of how to integrate atomic multi-path
payments (AMP) into Lightning. The existence of such a construct allows a
sender to atomically split a payment flow amongst several individual payment
flows. As a result, larger channels aren't as important as it's possible to
utilize one total outbound payment bandwidth to send several channels.
Additionally, in order to support the increased load, internal routing nodes
are incensed have more active channels. The existence of AMP-like payments
may also increase the longevity of channels as there'll be smaller, more
numerous payment flows, making it unlikely that a single payment comes
across unbalances a channel entirely. We've also showed how one can utilize
the current onion packet format to deliver additional data from a sender to
receiver, that's still e2e authenticated.

-- Conner && Laolu

_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180208/be98f021/attachment-0001.html>;

📅 Original date posted:2017-12-31 📝 Original message:On ...

2023-06-07T18:09:06Z

In reply to nevent1q…sjjz
_________________________

📅 Original date posted:2017-12-31
📝 Original message:On Sun, Dec 31, 2017 at 5:39 PM, CANNON via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I had a question relating to scaling and privacy enhancements.
> I believe that segwit combined with aggregated signatures
> and coinjoin can potentially achieve such. The idea is to
> use aggregated signatures in conjunction with coinjoin. So
> that all inputs of a coinjoin transaction would have a single
> signature vastly decreasing size while having privacy at the
> same time. If majority of transactions in a block did this I
> assume that significant more transactions could be fit into a
> block?

Here are some resources to read regarding signature aggregation and
scalability:

https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/
https://diyhpl.us/wiki/transcripts/gmaxwell-2017-08-28-deep-dive-bitcoin-core-v0.15/#signature-aggregation
https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/
https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
https://bitcointalk.org/index.php?topic=1377298.0
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
https://github.com/sipa/secp256k1/blob/968e2f415a5e764d159ee03e95815ea11460854e/src/modules/schnorr/schnorr.md
https://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171231/515a6708/attachment.html>;

📅 Original date posted:2017-09-12 📝 Original message:On ...

2023-06-07T18:05:56Z

In reply to nevent1q…j7g4
_________________________

📅 Original date posted:2017-09-12
📝 Original message:On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users. And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...

I have a reply to your point, but I want to clarify first that I am
not trying to provide any sort of criticism of your character, and to
any extent that my text is misinterpreted that way, that's entirely my
fault here. Anyway, here goes.

It's not enough to defend bitcoin and its users from active threats,
there is a more general responsibility to defend all kinds of users
and different software from many kinds of threats in whatever forms,
even if folks are using stupid and insecure software that you
personally don't maintain or contribute to or advocate for. Handling
knowledge of a vulnerability is a delicate matter and you might be
receiving knowledge with more serious direct or indirect impact than
originally described.

Besides the moral and ethical reasons to not unduly accelerate the
exploitation of a vulnerability, there is also a reputational
standpoint to consider, in that your position that your own (security)
work is credible is actually harmed by showing negative care for other
works by being first to publish either insecure software or knowledge
of a vulnerability. And sometimes the opposite is true: by not
disclosing knowledge of how a design is broken to someone inviting its
review, you're showing negative care in that way too, such as by
unintentionally encouraging the implementation of really bad ideas or
entirely novel misunderstandings of what you once thought were clear
concepts. So there is a difficult path to walk and especially in
security not all may be as it seems; caution is highly recommended.

Yes it would be good for "the market" to "get the signal" that
altcoins are insecure, and that some altcoin vendors are literally and
actively malicious entities, but I think everyone needs to take a step
back here and very carefully consider the color of their hats,
including those who advocate in the name of insecure downstream/forked
software.

The downside of the approach I've advocated for is that it requires
knowledge, thinking and outsmarting the red teams; I am certainly
aware of the allure of the approaches that involve absolutist
statements like "anything weak [including bitcoin if it does have
weaknesses] deserves to die and be actively exploited" but it's not
something I am interested in espousing...nor do I think it would be
healthy for this community to internalize that perspective. Instead we
should continue to work on highly defensible software, and keep
vigilant in regards to security. In "the [civilized] garden" I would
expect there to be a general understanding that people collaborate and
work together to build highly defensible evolving systems even if
there exists knowledge of vulnerabilities. But we shouldn't be
surprised when we don't go out of our way to contribute to
alternative/parasitic systems... and we shouldn't be encouraging each
other to actively bring about the eschaton by way of mishandling
knowledge of vulnerabilities...

I know these issues are difficult to get a handle on. Hopefully I've
provided some useful perspective.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2017-03-20 📝 Original ...

2023-06-07T17:57:38Z

In reply to nevent1q…tvvv
_________________________

📅 Original date posted:2017-03-20
📝 Original message:---------- Forwarded message ----------
From: Andrew Poelstra <apoelstra at wpsoftware.net>
Date: Mon, Mar 20, 2017 at 5:11 PM
Subject: [Mimblewimble] Lightning in Scriptless Scripts
To: mimblewimble at lists.launchpad.net

In my last post about scriptless scripts [2] I described a way to do
deniable atomic swaps by pre-sharing a difference of signatures. This
had the limitation that it required at least one party to be shared
between the signatures, allowed only pairwise linking, and required
both signatures to cover data that is known at the time of setup.
Linking a multi-hop Lightning channel with these constraints has proved
difficult.

* * *

Recently I've found a different construction that behaves much more like
a hash preimage challenge, and this can actually be used for Lightning.
Further, it supports reblinding, so you can learn a preimage but hide
which one you're looking for. (Ethan, one might actually overlap with
TumbleBit, sorry :)).

It works like this. We'll treat x -> xG as a hash function, so x is the
preimage of xG. There are two separate but related things I can do: (a)
construct a signature which reveals the preimage; or (b) create a
"pre-signature" which can be turned into a signature with the help of
the preimage.

Here's how it works: suppose I send xG to Rusty and he wants to send
me coins conditional on my sending him x. Lets say I have key P1 and
nonce R1; he has key P2 and nonce R2. Together we're going to make a
multisignature with key P1 + P2 and Rusty is going to set things up
so that I can't complete the signature without telling him x.

Here we go.

0. We agree somehow on R1, R2, P1, P2.

1. We can both compute a challenge e = H(P1 + P2 || R1 + R2 || tx).

2. I send s' = k1 - x - x1e, where R1 = k1G and P1 = x1G. Note he
can verify I did so with the equation s'G = R1 - xG - eP1.

3. He now sends me s2 = k2 - x2e, which is his half of the multisig.

4. I complete the sig by adding s1 = k1 - x1e. The final sig is
(s1 + s2, R1 + R2).

Now as soon as this signature gets out, I can compute x = s1 - s'.

* * *

Ok, pretty nifty. But now suppose Rusty wants to receive coins conditioned
on him revealing x, say, because he's a middle hop in a Lightning channel.
You might think he could act the same as I did in step (2), computing
s' = k1 - x - x1e, but actually he can't, because he doesn't know x himself!
All good. Instead he does the following.

To put names on things, let's say he's taking coins from Tadge. The
protocol is almost the same as above.

0. They agree somehow on R1, R2, P1, P2. Tadge's key and nonce are
R1 and P1, but there's a catch: P1 = x1G as before, but now
R1 - xG = k1G. That is, his nonce is offset by k1G.

1. They can both compute a challenge e = H(P1 + P2 || R1 + R2 || tx).

2. Tadge sends the "presignature" s' = k1 - x1e. Rusty can verify this
with the equation s'G = R1 - xG - eP1.

3. Now whenever Rusty obtains x, he can compute s1 = s' - x, which is
Tadge's half of the final signature.

4. Rusty computes s2 himself and completes the signature.

* * *

Ok, even cooler. But the real Rusty complained about these stories, saying
that it's a privacy leak for him to use the same xG with me as he used with
Tadge. In a onion-routed Lightning channel, this xG-reuse would let all
any two participants in a path figure out that they were in one path, if
they were colluding, even if they weren't directly connected.

No worries, we can fix this very simply. Rusty chooses a reblinding factor
rG. I give him x, as before, but what Tadge demands from him is (x + r).
(I give xG to Rusty as a challenge; he forwards this as xG + rG to Tadge.)
Since Rusty knows r he's able to do the translation. The two challenges
appear uniformly independently random to any observers.

* * *

Let's put this together into my understanding of how Lightning is supposed
to work. Suppose Andrew is trying to send coins to Drew, through Bob and
Carol. He constructs a path

A --> B --> C --> D

where each arrow is a Lightning channel. Only Andrew knows the complete
path, and is onion-encrypting his connections to each participant (who
know the next and previous participants, but that's it).

He obtains a challenge T = xG from D, and reblinding factors U and V
from B and C. Using the above tricks,

1. A sends coins to B contingent on him learning the discrete logarithm
of T + U + V.

2. B sends coins to C contingent on him learning the discrete logarithm
of T + V. (He knows the discrete log of U, so this is sufficient for
him to meet Andrew's challenge.)

3. C sends to D contingent on him learning the discrete log of T, which
is D's original challenge. Again, because C knows the discrete log
of V, this is sufficient for her to meet B's challenge.

The resulting path consists of transactions which are signed with single
uniformly random independent Schnorr signatures. Even though they're all
part of an atomic Lightning path.

* * *

Note that the s' values need to be re-communicated every time the
transaction
changes (as does the nonce). Because it depends on the other party's nonce,
this might require an additional round of interaction per channel update.

Note also that nothing I've said depends at all on what's being signed. This
means this works just as well for MimbleWimble as it would for
Bitcoin+Schnorr
as it would for Monero (with a multisig ring-CT construction) as it would
for Ethereum+Schnorr. Further, it can link transactions across chains.

I'm very excited about this.

Cheers
Andrew

[1] https://lists.launchpad.net/mimblewimble/msg00036.html

--
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
who can never find their peace,
whether north or south or west or east"
--Joanna Newsom

--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble at lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp

--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/4b59a31e/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 464 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/4b59a31e/attachment.sig>;

📅 Original date posted:2016-08-17 📝 Original message:On ...

2023-06-07T17:52:54Z

In reply to nevent1q…qvk7
_________________________

📅 Original date posted:2016-08-17
📝 Original message:On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>

"Welcome to my threat model."

In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.

I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.

Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.

As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.

Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.

((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/5492f37f/attachment.html>;

📅 Original date posted:2016-05-09 📝 Original message:On ...

2023-06-07T17:50:20Z

In reply to nevent1q…kf3j
_________________________

📅 Original date posted:2016-05-09
📝 Original message:On Mon, May 9, 2016 at 8:57 AM, Tom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The moderators failed to catch his aggressive tone while moderating my post
> (see archives) for being too aggressive.
>

IIRC you were previously informed by moderators (on the same reddit thread
to which you refer) that it would seem you had canceled your email from the
moderation queue, contrary to your retelling above. This is now reaching
far into off-topic and further posts on this subject should be sent to
bitcoin-discuss at lists.linuxfoundation.org or
bitcoin-dev-owners at lists.linuxfoundation.org instead of the bitcoin-dev
mailing list.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160509/041d1aa5/attachment-0001.html>;

📅 Original date posted:2016-03-02 📝 Original message:On ...

2023-06-07T17:49:34Z

In reply to nevent1q…tfea
_________________________

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:

> We are coming up on the subsidy halving this July, and there have been some
>

Luke,

One reason "hard-fork to fix difficulty drop algorithm" could be
controversial is that the proposal involves a hard-fork (perhaps
necessarily so, at my first and second glance). There are a number of
concerns with hard-forks including security, deployment, participation,
readiness measurement, backwards incompatibility, etc. In fact, some
Bitcoin Core developers believe that hard-forks are not a good idea and
should not be used.

# Hard-forks

An interesting (unspoken?) idea I’ve heard from a few people has been “we
should try to avoid all hard-forks because they are backwards
incompatible”, another thought has been "there should only be one more
hard-fork if any" and/or "there should only be one hard-fork every 30
years". I also recognize feedback from others who have mentioned "probably
unrealistic to expect that the consensus layer can be solidified this early
in Bitcoin's history". At the same time there are concerns about “slippery
slopes”....

Also, if you are going to participate in a hard-fork then I think you
should make up some proposals for ensure minimal monetary loss on the old
(non-hard-forked) chain, especially since your proposed timeline is so
short seems reasonable to expect even more safety-related due diligence to
minimize money loss (such as using a new address prefix on the hard-forked
upgrade). Anyway, it should be clear that hard-forks are an unsettled issue
and are controversial in ways that I believe you are already aware about.

# Have miners gradually reduce their hashrate instead of using a step
function cliff

adam3us recently proposed that miners who are thinking of turning off
equipment should consider gradually ramping down their hashrate, as a show
of goodwill (and substantial loss to themselves, similar to how they would
incur losses from no longer mining after the halving). This is not
something the consensus algorithm can enforce at the moment, and this
suggestion does not help under adversarial conditions. Since this
suggestion does not require a hard-fork, perhaps some effort should be made
to query miners and figure out if they need assistance with implementing
this (if they happen to be interested).

# Contingency planning

Having said all of the negative things above about hard-forks, I will add
that I do actually like the idea of having backup plans available and
tested and gitian-built many weeks ahead of expected network event dates.
Unfortunately this might encourage partial consensus layer hard-forks in
times of extreme uncertainty such as "emergencies".... creating an even
further emergency.

# "Indefinite backlog growth"

You write "the backlog would grow indefinitely until the adjustment
occurs". This seems to be expected behavior regardless of difficulty
adjustment (in fact, a backlog could continue to grow even once difficulty
adjusts downward), and the consensus protocol does not commit to
information regarding that backlog anyway...

# Difficulty adjustment taking time is expected

This is an expected part of the protocol, it's been mentioned since
forever, it's well known and accounted for. Instead, we should be providing
advice to users about which alternative payment systems they should be
using if they expect instantaneous transaction confirmations. This has been
a long-standing issue, and rolling out a hard-fork is not going to fix
mistaken assumptions from users. They will still think that confirmations
were meant to be instantaneous regardless of how many hard-forks you choose
to deploy.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/aefad2cc/attachment.html>;

📅 Original date posted:2016-02-04 📝 Original message:On ...

2023-06-07T17:48:30Z

In reply to nevent1q…9rtu
_________________________

📅 Original date posted:2016-02-04
📝 Original message:On Thu, Feb 4, 2016 at 11:56 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> past the triggering block. A block-chain re-org of two thousand or
>> more blocks on the main Bitcoin chain is unthinkable-- the economic
>> chaos would be massive, and the reaction to such a drastic (and
>> extremely unlikely) event would certainly be a hastily imposed
>> checkpoint to get everybody back onto the chain that everybody was
>> using for economic transactions.
>>
>
> No, the "triggering block" you mentioned is NOT where the hardfork starts.
> Using BIP101 as an example, the hardfork starts when the first >1MB is
> mined. For people who failed to upgrade, the "grace period" is always zero,
> which is the moment they realize a hardfork.
>

Are there any plans written down anywhere about the "hastily imposed
checkpoint" scenario? As far as I know, we would have to check-point on
both blockchains because of the way that hard-forks work (creating two
separate chains and/or networks). Nothing about this should be an
"emergency", we have all the time in the world to prepare a safe and
responsible way to upgrade the network without unilaterally
declaring obsolescence.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/21af804f/attachment.html>;

📅 Original date posted:2015-12-19 📝 Original message:On ...

2023-06-07T17:46:46Z

In reply to nevent1q…7ww8
_________________________

📅 Original date posted:2015-12-19
📝 Original message:On Fri, Dec 18, 2015 at 6:18 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Anyway, we should write this up as a BIP - there's been a tremendous
> amount of misinformation, even flat out lies, floating around on this
> subject.
>

Er, this sounds like something that should go into bip99. Right?

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/a2ae7187/attachment.html>;

📅 Original date posted:2015-12-10 📝 Original message:On ...

2023-06-07T17:46:07Z

In reply to nevent1q…426z
_________________________

📅 Original date posted:2015-12-10
📝 Original message:On Thu, Dec 10, 2015 at 12:47 AM, jl2012 wrote:
> 3. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this one
> has the highest priority as it makes offline signing much easier.

nhashtype proposal:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

OP_CODESEPARATOR:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007802.html

summary email about sighash type proposals (which IIRC you saw, so
leaving this link here is mainly for the benefit of others):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-12-10 📝 Original message:On ...

2023-06-07T17:45:59Z

In reply to nevent1q…e9fs
_________________________

📅 Original date posted:2015-12-10
📝 Original message:On Wed, Dec 9, 2015 at 9:58 PM, Akiva Lichtner wrote:
> Correct me if I am wrong, but the dream of a virtual currency where
> everybody is equal and runs the client on their mobile device went out the
> window long ago. I think that went out with the special mining hardware. If

Mining equipment isn't for transaction verification. The mining
equipment is used to work on Proof-of-Work. Thanks.

> my organization had to accept bitcoin payments I would assume that we'll
> need a small server farm for transaction verification, and that we would see

Unfortunately Bitcoin does not work like those centralized systems; it
should not be surprising that a system focused so much on
decentralized and independent verification would have developers
working on so many non-bandwidth scaling solutions. These other
proposals seek to preserve existing properties of Bitcoin (such as
cheap verification, low-bandwidth) while also increasing the amount of
activity that can enjoy the decentralized fruits of Proof-of-Work
labor. But not helpful to assume this can only look like Visa or any
database on a cluster etc...

> would be entirely okay for a guy on a smartphone to delegate verification to
> a trusted party, as long as the trust chain stops there and there is plenty
> of choice.

I don't suppose I could tempt you with probabilistically checkable
proofs, could I? These verify in milliseconds, grow sublinear in size
of the total data, but have no near-term proposal available yet.

> I am guessing the trustless virtual currency police would get pretty upset
> about such a pragmatic approach, but it's not really a choice, the failure
> to scale has already occurred. All things considered I think that Bitcoin

Perhaps instead of failure-to-scale you mean "failure to apply
traditional scaling has already failed", which shouldn't be so
surprising given the different security model that Bitcoin operates
on.

> most people trust at least one other person, so it's not that weird.

see the following recent text,
"""
Bitcoin is P2P electronic cash that is valuable over legacy systems
because of the monetary autonomy it brings to its users through
decentralization. Bitcoin seeks to address the root problem with
conventional currency: all the trust that's required to make it work--

-- Not that justified trust is a bad thing, but trust makes systems
brittle, opaque, and costly to operate. Trust failures result in systemic
collapses, trust curation creates inequality and monopoly lock-in, and
naturally arising trust choke-points can be abused to deny access to
due process. Through the use of cryptographic proof and decentralized
networks Bitcoin minimizes and replaces these trust costs.

With the available technology, there are fundamental trade-offs between
scale and decentralization. If the system is too costly people will be
forced to trust third parties rather than independently enforcing the
system's rules. If the Bitcoin blockchain’s resource usage, relative
to the available technology, is too great, Bitcoin loses its competitive
advantages compared to legacy systems because validation will be too
costly (pricing out many users), forcing trust back into the system.
If capacity is too low and our methods of transacting too inefficient,
access to the chain for dispute resolution will be too costly, again
pushing trust back into the system.
"""

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-12-08 📝 Original message:On ...

2023-06-07T17:45:54Z

In reply to nevent1q…eqaj
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> and miners would have to round-robin through partitions

At first glance this proposal seems most similar to the sharding proposals:

http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
https://www.reddit.com/r/Bitcoin/comments/3u1m36/why_arent_we_as_a_community_talking_about/cxbamhn
http://eprint.iacr.org/2015/1168.pdf (committee approach)

> but clients would have to send more than one message in order to spend money

Offloading work to the client for spends has in the past been a
well-received concept, such as the linearized coin history idea.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-12-07 📝 Original message:On ...

2023-06-07T17:45:34Z

In reply to nevent1q…ug9r
_________________________

📅 Original date posted:2015-12-07
📝 Original message:On Mon, Dec 7, 2015 at 4:02 PM, Gregory Maxwell wrote:
> The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating
> proposals were presented. I think this would be a good time to share my
> view of the near term arc for capacity increases in the Bitcoin system. I
> believe we’re in a fantastic place right now and that the community
> is ready to deliver on a clear forward path with a shared vision that
> addresses the needs of the system while upholding its values.

ACK.

One of the interesting take-aways from the workshops for me has been
that there is a large discrepancy between what developers are doing
and what's more widely known. When I was doing initial research and
work for my keynote at the Montreal conference (
http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf -- an
attempt at being exhaustive, prior to seeing the workshop proposals ),
what I was most surprised by was the discrepancy between what we think
is being talked about versus what has been emphasized or socially
processed (lots of proposals appear in text, but review efforts are
sometimes "hidden" in corners of github pull request comments, for
example). As another example, the libsecp256k1 testing work reached a
level unseen except perhaps in the aerospace industry, but these sorts
of details are not apparent if you are reading bitcoin-dev archives.
It is very hard to listen to all ideas and find great ideas.
Sometimes, our time can be almost completely exhausted by evaluating
inefficient proposals, so it's not surprising that rough consensus
building could take time. I suspect we will see consensus moving in
positive directions around the proposals you have highlighted.

When Satoshi originally released the Bitcoin whitepaper, practically
everyone-- somehow with the exception of Hal Finney-- didn't look,
because the costs of evaluating cryptographic system proposals is so
high and everyone was jaded and burned out for the past umpteen
decades. (I have IRC logs from January 10th 2009 where I immediately
dismissed Bitcoin after I had seen its announcement on the
p2pfoundation mailing list, perhaps in retrospect I should not let
family tragedy so greatly impact my evaluation of proposals...). It's
hard to evaluate these proposals. Sometimes it may feel like random
proposals are review-resistant, or designed to burn our time up. But I
think this is more reflective of the simple fact that consensus takes
effort, and it's hard work, and this is to be expected in this sort of
system design.

Your email contains a good summary of recent scaling progress and of
efforts presented at the Hong Kong workshop. I like summaries. I have
previously recommended making more summaries and posting them to the
mailing list. In general, it would be good if developers were to write
summaries of recent work and efforts and post them to the bitcoin-dev
mailing list. BIP drafts are excellent. Long-term proposals are
excellent. Short-term coordination happens over IRC, and that makes
sense to me. But I would point out that many of the developments even
from, say, the Montreal workshop were notably absent from the mailing
list. Unless someone was paying close attention, they wouldn't have
noticed some of those efforts which, in some cases, haven't been
mentioned since. I suspect most of this is a matter of attention,
review and keeping track of loose ends, which can be admittedly
difficult.

Short (or even long) summaries in emails are helpful because they
increase the ability of the community to coordinate and figure out
what's going on. Often I will write an email that summarizes some
content simply because I estimate that I am going to forget the
details in the near future, and if I am going to forget them then it
seems likely that others might.... This creates a broad base of
proposals and content to build from when we're doing development work
in the future, making for a much richer community as a consequence.
The contributions from the scalingbitcoin.org workshops are a welcome
addition, and the proposal outlined in the above email contains a good
summary of recent progress. We need more of this sort of synthesis,
we're richer for it. I am excitedly looking forward to the impending
onslaught of Bitcoin progress.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-10-14 📝 Original message:On ...

2023-06-07T17:43:27Z

In reply to nevent1q…00vh
_________________________

📅 Original date posted:2015-10-14
📝 Original message:On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> while the whitepaper has all the nitty gritty details:
> http://arxiv.org/abs/1510.02037

Taking reward compensation back by fraud proofs is not enough to fix
the problems associated with double spending (such as, everyone has to
wait for the "real" confirmations instead of the "possibly
double-spend" confirmations). Some of this was discussed in -wizards
recently:
http://gnusha.org/bitcoin-wizards/2015-09-19.log

For a system based entirely on fraud proofs and threat of fraud
proofs, see fidelity-bonded ledgers:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002189.html
https://bitcointalk.org/index.php?topic=146307.0

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-08-30 📝 Original message:Here ...

2023-06-07T17:38:43Z

In reply to nevent1q…l7wq
_________________________

📅 Original date posted:2015-08-30
📝 Original message:Here is a short review of previously-proposed and exotic SIGHASH types.

SIGHASH_MULTIPLE
SIGHASH_LIST:
https://bitcointalk.org/index.php?topic=252960.0
https://bitcointalk.org/index.php?topic=212555.0

SIGHASH_MULTIPLE
SIGHASH_WITHINPUTVALUE:
https://bitcointalk.org/index.php?topic=191003.0

SIGHASH_WITHINPUTVALUE:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007185.html

SIGHASH_NOINPUT:
https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4
http://lightning.network/lightning-network-paper.pdf

SIGHASH_NORMALIZED
SIGHASH_NOINPUT:
http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2015-02-23-scaling-bitcoin-to-billions-of-transactions-per-day/

SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY
SIGHASH_WITHOUT_PREV_VALUE
SIGHASH_WITHOUT_INPUT_TXID
SIGHASH_WITHOUT_INPUT_INDEX
SIGHASH_WITHOUT_INPUT_SEQUENCE
SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY
SIGHASH_WITHOUT_OUTPUT_VALUE
SIGHASH_WITHOUT_INPUTS
SIGHASH_WITHOUT_OUTPUTS
SIGHASH_WITHOUT_INPUT_SELF
SIGHASH_WITHOUT_OUTPUT_SELF
SIGHASH_WITHOUT_TX_VERSION
SIGHASH_WITHOUT_TX_LOCKTIME
SIGHASH_SIGN_STACK_ELEMENT:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

Similarly, petertodd has asked for a SIGHASH_DONT_SIGN_TXID before to
make OP_CODESEPARATOR more useful.

SIGHASH_DANGEROUSLYPROMISCUOUS:
http://gnusha.org/bitcoin-wizards/2015-04-17.log

SIGHASH_DOUBLE:
06:41 < lorenzoasr> maybe a SIGHASH_DOUBLE that signs INPUT[i] and
OUTPUT[i] and OUTPUT[i+1] could be very helpful

Some sighash types briefly proposed by petertodd in #bitcoin-dev:
SIGHASH_NLOCKTIMEVERIFY
SIGHASH_SUM (for merging multiple payments)

And finally one from wumpus (#bitcoin-dev):
SIGHASH_UNICORN

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-08-15 📝 Original message:On ...

2023-06-07T17:35:13Z

In reply to nevent1q…j8jx
_________________________

📅 Original date posted:2015-08-15
📝 Original message:On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> These are the people who used to run around saying that Bitcoin
> development is "decentralized" because anyone can fork the code and now
> many of the same people claim a fork will destroy everything.

You may be misremembering; nobody has ever disagreed that you can fork a
source code repository. Perhaps you are thinking instead about the concerns
regarding "asymmetric" rule incompatibilities?

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/7385744d/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T17:33:44Z

In reply to nevent1q…suwz
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that lightning / hub and spoke do not meet requirements for users
> wishing to participate in global consensus, because they are not global
> consensus networks, since all participating nodes are not aware of all
> transactions.

You don't need consensus on the lightning network because you are
using bitcoin consensus anyway. Commitment transactions are deep
enough in the blockchain history that removing that transaction from
the history is impractical. The remaining guarantees are ensured by
the properties of the scripts in the transaction. You don't need to
see all the transactions, but you do need to look at the transactions
you are given and draw conclusions based on the details to see whether
their commitments are valid or the setup wasn't broken.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-08-07 📝 Original message:On ...

2023-06-07T17:33:36Z

In reply to nevent1q…uwk4
_________________________

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or less
> full nodes if we reduce the block size?

Some arguments have floated around that even in the absence of "causing an
increase in the number of full nodes", that a reduction of the max block
size might be beneficial for other reasons, such as bandwidth saturation
benefits. Also less time spent validating transactions because of the fewer
transactions.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/564f5483/attachment.html>;

📅 Original date posted:2015-08-15 📝 Original message:On ...

2023-06-07T15:47:04Z

In reply to nevent1q…hv8d
_________________________

📅 Original date posted:2015-08-15
📝 Original message:On Sat, Aug 15, 2015 at 3:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> These are the people who used to run around saying that Bitcoin
> development is "decentralized" because anyone can fork the code and now
> many of the same people claim a fork will destroy everything.

You may be misremembering; nobody has ever disagreed that you can fork a
source code repository. Perhaps you are thinking instead about the concerns
regarding "asymmetric" rule incompatibilities?

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/7385744d/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:On ...

2023-06-07T15:45:51Z

In reply to nevent1q…m0sz
_________________________

📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 1:46 PM, Michael Naber via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that lightning / hub and spoke do not meet requirements for users
> wishing to participate in global consensus, because they are not global
> consensus networks, since all participating nodes are not aware of all
> transactions.

You don't need consensus on the lightning network because you are
using bitcoin consensus anyway. Commitment transactions are deep
enough in the blockchain history that removing that transaction from
the history is impractical. The remaining guarantees are ensured by
the properties of the scripts in the transaction. You don't need to
see all the transactions, but you do need to look at the transactions
you are given and draw conclusions based on the details to see whether
their commitments are valid or the setup wasn't broken.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-08-07 📝 Original message:On ...

2023-06-07T15:45:44Z

In reply to nevent1q…jyqk
_________________________

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or less
> full nodes if we reduce the block size?

Some arguments have floated around that even in the absence of "causing an
increase in the number of full nodes", that a reduction of the max block
size might be beneficial for other reasons, such as bandwidth saturation
benefits. Also less time spent validating transactions because of the fewer
transactions.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/564f5483/attachment.html>;

📅 Original date posted:2015-07-30 📝 Original message:On ...

2023-06-07T15:44:15Z

In reply to nevent1q…0e4d
_________________________

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Stated differently, if the cost or contention of using the network rises
> to the point of excluding the average user from making transactions, then
> they probably aren't going to care that they can run a node at trivial cost.

That's an interesting claim; so suppose you're living in a future where
transactions are summarizing millions or billions of other daily
transactions, possibly with merkle hashes. You think that because a user
can't individually broadcast his own personal transaction, that the user
would not be interested in verifying the presence of a summarizing
transaction in the blockchain? I'm just curious if you could elaborate on
this effect. Why would I need to see my individual transactions on the
network, but not see aggregate transactions that include my own?

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/d842494e/attachment.html>;

📅 Original date posted:2015-07-30 📝 Original message:On ...

2023-06-07T15:44:01Z

In reply to nevent1q…jf43
_________________________

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 9:52 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> What makes you think that when there is such a low availability of
> transaction
> space that paying to be included costs you $10, that Bitcoin is not going
> to
> be outcompeted and replaced or otherwise regarded as worthless?
>

Ah, well that's simple. Because any decentralized system is going to have
high transaction costs and scarcity anyway. So far the only mechanism we
know for how to do this is something like bitcoin. As a centralized system,
bitcoin is already strongly outcompeted by many, many other designs, so
that shouldn't be very surprising I think.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/96d4dabe/attachment.html>;

📅 Original date posted:2015-06-24 📝 Original message:On ...

2023-06-07T15:40:03Z

In reply to nevent1q…d03p
_________________________

📅 Original date posted:2015-06-24
📝 Original message:On Wed, Jun 24, 2015 at 6:49 PM, Jeff Garzik <jgarzik at gmail.com> wrote:

> There is no voting in the way you think. Devs commit changes the users
> will accept and use. Users "fire" developers by choosing different devs or
> different software.

I think that statement is too weak. Users are all personally responsible
for evaluating all rules for themselves. Many have chosen and will continue
to choose to just keep an ear out for rule changes that they may be
interested in using. Ever user should be educated on this topic...
otherwise there are too many principal agent problems, even with the
ability to "fire" developers (a.k.a "use different software"). It's similar
to the reasons why it's important to see all the transactions on the
network.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/92da5acc/attachment.html>;

📅 Original date posted:2015-06-15 📝 Original message:On ...

2023-06-07T15:38:11Z

In reply to nevent1q…p8xp
_________________________

📅 Original date posted:2015-06-15
📝 Original message:On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike at plan99.net> wrote:

> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
> non-technical, stupid, uninformed, etc .... OK, go ahead and show them the
> error of their ways. Anyone can write blogs.
>

I worry that if this is the level of care you take with reading and
(mis)interpreting Adam's messages, that you might not be taking extreme
care with evaluating consensus changes, even while tired or sleeping. I
encourage you to evaluate both messages and source code more carefully,
especially in the world of bitcoin. However, this goes for everyone and not
just you. Specifically, when Adam mentioned your conversations with
non-technical people, he did not mean "Mike has talked with people who have
possibly not made pull requests to Bitcoin Core, so therefore Mike is a
non-programmer". Communication is difficult and I can understand that, but
we really have to be more careful when evaluating each other's messages;
technical miscommunication can be catastrophic in this context. On the
topic of whether you are a programmer, I suspect that ever since you built
CIA.vc we have all known you're a programmer, Mike.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/f4ffeedf/attachment.html>;

📅 Original date posted:2015-05-08 📝 Original message:On ...

2023-06-07T15:33:57Z

In reply to nevent1q…wtrn
_________________________

📅 Original date posted:2015-05-08
📝 Original message:On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> - Perhaps the hard block size limit should be a function of the actual block sizes over some
> trailing sampling period. For example, take the median block size among the most recent
> 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically,
> rather than having human beings guessing at what is an appropriate limit.

Block contents can be grinded much faster than hashgrinding and
mining. There is a significant run-away effect there, and it also
works in the gradual sense as a miner probabilistically mines large
blocks that get averaged into that 2016 median block size computation.
At least this proposal would be a slower way of pushing out miners and
network participants that can't handle 100 GB blocks immediately.. As
the size of the blocks are increased, low-end hardware participants
have to fall off the network because they no longer meet the minimum
performance requirements. Adjustment might become severely mismatched
with general economic trends in data storage device development or
availability or even current-market-saturation of said storage
devices. With the assistance of transaction stuffing or grinding, that
2016 block median metric can be gamed to increase faster than other
participants can keep up with or, perhaps worse, in a way that was
unintended by developers yet known to be a failure mode. These are
just some issues to keep and mind and consider.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-05-07 📝 Original message:On ...

2023-06-07T15:33:09Z

In reply to nevent1q…y5nh
_________________________

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 9:05 AM, Mike Hearn <mike at plan99.net> wrote:
> Maybe you dislike that idea. It's so .... centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.

Hmm, git repositories don't quite work like that. Instead, you should
imagine everyone having a local copy of the git repository. Each
developer synchronizes their git repository with other developers.
They merge changes from specific remote branches that they have
received. Each developer has their own branch and each developer is
the "single decision maker" for the artifact that they compile.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-05-06 📝 Original message:On ...

2023-06-07T15:33:03Z

In reply to nevent1q…5m2l
_________________________

📅 Original date posted:2015-05-06
📝 Original message:On Wed, May 6, 2015 at 5:12 PM, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.

Well, there has been significant public discussion in #bitcoin-wizards
on irc.freenode.net which is available in public logs, specifically
about why increasing the max block size is kicking the can down the
road while possibly compromising blockchain security. There were many
excellent objections that were raised that, sadly, I see are not
referenced at all in the recent media blitz. Frankly I can't help but
feel that if contributions, like those from #bitcoin-wizards, have
been ignored in lieu of technical analysis, and the absence of
discussion on this mailing list, that I feel perhaps there are other
subtle and extremely important technical details that are completely
absent from this--and other-- proposals. I have some rather general
thoughts to offer.

Secured decentralization is the most important and most interesting
property of bitcoin. Everything else is rather trivial and could be
achieved millions of times more efficiently with conventional
technology. Our technical work should be informed by the technical
nature of the system we have constructed.

I suspect that as bitcoin continues to grow in all dimensions and
metrics, that we will see an unending wave of those who are excited by
the idea of Something Different in the face of archaic, crumbling
software and procedures in the rest of the financial world. Money has
found its way into every aspect of human life. There's no doubt in my
mind that bitcoin will always see the most extreme campaigns and the
most extreme misunderstandings. Like moths to a flame or water in the
desert, almost everyone is excited by ANY status quo change
whatsoever. This is something that we have to be vigilante about,
because their excitement is motivation to do excellent work, not
simply any work. For some who are excited about general status quo
changes that bitcoin represents, they may not mind if bitcoin
decentralization disappears and is replaced with just a handful of
centralized nodes. Whereas for development purposes we must hold
ourselves to extremely high standards before proposing changes,
especially to the public, that have the potential to be unsafe and
economically unsafe. We have examples from NASA about how to engineer
extremely fault tolerant systems, and we have examples from Linux
about how to have high standards in open-source projects. Safety is
absolutely critical, even in the face of seemingly irrational
excuberance of others who want to scale to trillions of daily coffee
transactions individually stored forever in the blockchain.

When designing bitcoin or even some other system, an important design
target is what the system should be capable of. How many transactions
should the system perform? What is the correct number of transactions
for a healthy, modern civilization to perform every day? And how fast
should that (not) grow? Should we allow for 2 billion trillion coffee
transactions every day, or what about 100 trillion transactions per
second? I suspect that these sorts of questions are entirely
unanswerable and boring. So in the absence of technical targets to
reach during the design phase, I suspect that Jeff Garzik was right
when he pointed out a few months ago that bitcoin is good at
settlement and clearing. There are many potential technical solutions
for aggregating millions (trillions?) of transactions into tiny
bundles. As a small proof-of-concept, imagine two parties sending
transactions back and forth 100 million times. Instead of recording
every transaction, you could record the start state and the end state,
and end up with two transactions or less. That's a 100 million fold,
without modifying max block size and without potentially compromising
secured decentralization.

The MIT group should listen up and get to work figuring out how to
measure decentralization and its security :-). Maybe we should be
collectively pestering Andrew Miller to do this, too. No pressure,
dude. Getting this measurement right would be really beneficial
because we would have a more academic and technical understanding to
work with. I would also characterize this as high priority next to the
"formally verified correctness proofs for Script and
libbitcoinconsensus".

Also, I think that getting this out in the open on this mailing list
is an excellent step forward.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-03-12 📝 Original message:On ...

2023-06-07T15:31:30Z

In reply to nevent1q…pn6f
_________________________

📅 Original date posted:2015-03-12
📝 Original message:On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> For an emergency transition the user is probably better off with an
> explicit unstructured mass private key export, and a sweep function;
> and guaranteeing compatibility with that is much easier; and because
> it moves funds in one direction there is much less chance of going
> from secure to insecure.

I haven't looked at the existing sweep implementations, but it would
be unfortunate if sweep functions were not available that create at
least the same number of keys, or possibly more, for the purposes of
sweeping. I suppose there are different levels of emergency, where
perhaps you want to sweep all at once in a single transaction and lose
out on (already nebulous) privacy benefits. I say nebulous because
broadcasting a bunch of transactions all at the same time during the
sweep can compromise privacy even when the transactions have no common
ancestor outputs.

- Bryan
http://heybryan.org/
1 512 203 0507

📅 Original date posted:2015-02-14 📝 Original message:On ...

2023-06-07T15:30:34Z

In reply to nevent1q…evng
_________________________

📅 Original date posted:2015-02-14
📝 Original message:On Sat, Feb 14, 2015 at 1:04 PM, Adam Back <adam at cypherspace.org> wrote:

> That its highly complex to maintain strict consensus between bitcoin
> versions, does not justify consensus rewrite experiments

Correct. However, those maintenance costs absolutely do justify working
towards formal proofs of correctness for the existing implementation. These
plans are no secret and are publicly discussed, but I think it would be
instrumental to outsiders if the correctness plans and ongoing progress
could be mentioned whenever a warning is made about unjustified and
dangerous Bitcoin consensus rewrite attempts.

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/67b27d76/attachment.html>;

📅 Original date posted:2014-08-19 📝 Original message:On ...

2023-06-07T15:25:29Z

In reply to nevent1q…7kls
_________________________

📅 Original date posted:2014-08-19
📝 Original message:On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> As a first step, one possibility is putting the primary repo on
> bitcoin.org somewhere, and simply mirroring that to github for each
> push.

Smaller first step would be to mirror the git repository on
bitcoin.org, which is necessary anyway before switching primaries.

- Bryan
http://heybryan.org/
1 512 203 0507