Omar Shibli [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-09-01 to 2020-12-23
💬 Posted a total of 13 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, META
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:54:37

- reply

📅 Original date posted:2019-03-18
📝 Original message:
So what to do? I registered there, how to stay subscribed to both mailing
lists, please.
On Mon, Mar 18, 2019 at 9:23 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Is there anything I need to do if I want to remain on lightning-dev?
> Or is this automatic as long as I do not unsubscribe?
>
> Regards,
> ZmnSCPxj
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, March 16, 2019 12:45 PM, Rusty Russell <rusty at blockstream.com>
> wrote:
>
> > Hi all,
> >
> > Linux Foundation (who graciously host this list for us) is
> > deprecating their mailing list infrastructure (mailman2 is unmaintained,
> > apparently v3 is a mess), and migrating lists to groups.io. Apparently
> > this is the direction that bitcoin-dev is heading.
> >
> > Unless people raise concerns, I expect this list to follow, within the
> > week. If you want to unsubscribe before then, please do so.
> >
> > Cheers,
> > Rusty.
> >
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190318/fefd5a76/attachment.html>

2023-06-09 12:54:37

- reply

📅 Original date posted:2019-03-20
📝 Original message:
Cool cool.
Best,
Omar
On Tue, Mar 19, 2019 at 4:57 AM Rusty Russell <rusty at blockstream.io> wrote:
> Yes, you shouldn't notice anything, and don't need to do anything.
>
> Cheers,
> Rusty.
>
> On Mon, Mar 18, 2019, 17:53 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Is there anything I need to do if I want to remain on lightning-dev?
>> Or is this automatic as long as I do not unsubscribe?
>>
>> Regards,
>> ZmnSCPxj
>>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Saturday, March 16, 2019 12:45 PM, Rusty Russell <
>> rusty at blockstream.com> wrote:
>>
>> > Hi all,
>> >
>> > Linux Foundation (who graciously host this list for us) is
>> > deprecating their mailing list infrastructure (mailman2 is unmaintained,
>> > apparently v3 is a mess), and migrating lists to groups.io. Apparently
>> > this is the direction that bitcoin-dev is heading.
>> >
>> > Unless people raise concerns, I expect this list to follow, within the
>> > week. If you want to unsubscribe before then, please do so.
>> >
>> > Cheers,
>> > Rusty.
>> >
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190320/6f60868d/attachment.html>

2023-06-09 12:54:35

- reply

📅 Original date posted:2019-03-15
📝 Original message:
Hello Rene,
Sorry for hijacking this thread, but I would suggest another route to
tackle privacy and liquidity issues in general.
At the moment, it seems that there are no taking advantage of off-chain
settlement protocols, the idea is based on Schnorr signatures. The general
theme is build programable multi sig contracts based on aggregation of
signatures.
It's very powerful, and simple model, that will allow variety of
funding combinations.
The general diagram:
N inputs -> M outputs , N = a1s1 + a2s2 ... , M = b1s2 + b2s2
... (simplified incomplete formulas for clarity)
a1 - input amount , s1 - signature.. same to b1, b2....
The main advantage of this communication method that all transactions could
be done offline with trusted Oracle, optionally all data could be blinded
from oracle PoV for optimal privacy and maximal effect principle of least
authority through minimal visibility to third party participants.
Regards,
Omar
On Fri, Mar 15, 2019 at 6:29 PM lisa neigut <niftynei at gmail.com> wrote:
> Hello Rene,
>
> This is a legitimate concern. Thank you for raising it.
>
> I have three suggestions for how to mitigate this. The first is to return
> a non-specific error message which, while in the aggregate might be used to
> approximate a nodes’ uncommitted balance, would at least offer plausible
> deniability to the exact cause for the failure.
>
> The second proposal is in a similar vein. A node might add a privately
> held randomization vector, which would return an error to any open channel
> request with probability p. Thus an attacker wishing to ascertain a nodes
> balance would not know with any certainty if the request they sent failed
> because of a lack of available liquidity or for some other non-related
> reason.
>
> Finally, and perhaps most compellingly, rather than return an error, the
> open channel should always succeed, but for any value at or below the
> requested liquidity amount. The opening channel balance agreed upon between
> the two nodes would then be adjusted to reflect the “correct” amount of
> push_msat for the actual amount of funding_satoshi contributed by the
> accepter (i.e. zero if the accepter node sends accept_channel2 with a
> funding_satoshi balance of zero). If the amount of liquidity offered up by
> the accepter is unacceptable to the opener, then they may choose to fail
> the channel opening negotiation.
>
> This third proposal, combined with a randomization vector (i.e with
> probability p you always offer an amount less than the proposed amount)
> would remove some of the certainty around a nodes unconfirmed balance. As
> with channel balances, however, there is always the possibility of a
> probabilistic attack i.e. lots of open channel requests sent over a short
> period of time that would give an attacker a reasonable approximation of
> your nodes available balance. A node could mitigate this by including an
> exponential backoff for open channel requests from any one node,
> essentially rate limiting the number of open channel requests that it will
> accept from a single peer, or peers globally.
>
> A node may also choose to set a policy around what it considers reasonable
> liquidity requests from a peer (i.e. no more than 0.05 BTC from any peer),
> which would further limit their exposure on the upper end of information
> gathering.
>
> Finally, as this liquidity feature is optional, any node who is truly
> interested in preserving the privacy of their funds may continue to
> establish channels the old fashioned way, i.e. via out of band negotiation
> with other, trusted node operators.
>
> Cheers,
> Lisa
>
>
>
>
>
> On Fri, Mar 15, 2019 at 08:29 René Pickhardt via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Hey everyone,
>>
>> during the spec meeting we have discussed intensively about dual funded
>> channels and potential game theory with the fees however I now believe that
>> we missed out another important crucial part which is the privacy of the
>> node providing liquidity.
>>
>> While I have not seen a concrete example for a channel establishment
>> protocol that supports dual funded channels I have seen this proposal (
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html
>> ) for advertising channel liquidity which assumed that the `open_channel`
>> message would be modified as follows:
>>
>> `open_channel`:
>> new feature flag (channel_flags): option_liquidity_buy [2nd least
>> significant bit]
>> push_msat: set to fee payment for requested liquidity
>> [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
>> requested at channel open
>>
>> ...
>>
>> If a node cannot provide the liquidity requested in `open_channel`, it must
>> return an error.
>>
>> With such a protocol I could now (basically only at the cost of internet
>> traffic) probe a lower bound for the amount of BTC available by a node that
>> allows for dual funded channels and abort the channel establishing process
>> at some time before I ever spend / lock any of my own bitcoin.
>>
>> As I can even participate in the peer protocol without having a single
>> channel open this situation seems to be even more severe.
>>
>> I don't have a clear suggestion how to mitigate against this. One general
>> potential idea / solution would be to make spamming / probing more
>> expensive. For example we could require the person to open a channel first
>> and then ask the partner to splice something in (meaning we don't allow for
>> one tx dual funded channels). In that case the node requesting liquidity
>> had to do an onchain tx. also the requests to splice in can be identified
>> and the person who feels to be probed can choose to fail the channel. I am
>> not happy with my barrier as it would still be able to relatively cheaply
>> abuse this and we run into a whole bunch of game theory about fees again.
>>
>> As the lightning network seems very keen to provide strong privacy to its
>> users (c.f.: onion routing, keeping channel balances private, encrypted
>> transport layer,...) I thought it is worthwhile pointing out the problem
>> with the privacy for dual funded channels even though I don't have a
>> concrete solution yet.
>>
>> best Rene
>>
>>
>> --
>> https://www.rene-pickhardt.de
>>
>> Skype: rene.pickhardt
>>
>> mobile: +49 (0)176 5762 3618
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190315/8761f6a8/attachment.html>

2023-06-07 18:27:55

- reply

📅 Original date posted:2020-12-23
📝 Original message:That's a great idea, in traditional banking there are wide initiatives to
standardize components between different actors, most widely used is Open
Banking , i think regardless of the usage, it could be hardware or
software, there is a big value in standrizating communications between
different components.
Here is more info about Open Banking:
https://fin.plaid.com/articles/what-is-the-open-banking-standard/#:~:text=The%20Open%20Banking%20Standard%20relies,data%20through%20their%20bank%20accounts
On Wed, Dec 23, 2020 at 10:42 AM monokh via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for the input Luke.
>
> > 1) People should not be encouraged to write or use web browsers for
> their wallet.
>
> Indeed. Holding keys in the browser can be very insecure, however the spec
> is not limited to this. I will amend to make this clear. The same interface
> can be used to communicate from a web context or even desktop application
> with hardware wallets where keys are segregated safely. The prominent
> hardware wallets already have such an interface. Unfortunately as there has
> been no standardisation, an application must specifically provide an
> implementation for each wallet to be compatible.
>
> > 2) You may want to look over earlier work in this area.
>
> Please share if you have specifics in mind. What has been considered were
> mainly hardware wallet apis. The requests have been defined such that they
> would be compatible. I will make references to such considerations in the
> text. I welcome any feedback on what may be missing or problematic for
> these providers - something I will also pursue outwith the thread.
>
> -monokh
>
> On Wed, Dec 23, 2020 at 2:15 AM Luke Dashjr <luke at dashjr.org> wrote:
>
>> 1) People should not be encouraged to write or use web browsers for their
>> wallet.
>> 2) You may want to look over earlier work in this area.
>>
>> On Tuesday 22 December 2020 14:43:11 monokh via bitcoin-dev wrote:
>> > Hi
>> >
>> > This is a first draft of a BIP we intend to submit. The main intention
>> is
>> > to define a simple interface that wallets and applications can agree on
>> > that would cover the vast majority of use cases. This can enable writing
>> > bitcoin applications (e.g. time lock, multi sig) on the web that can be
>> > seamlessly used with any compatible wallets. We have implementations of
>> > such examples but I don't want to turn this thread into a promotion and
>> > rather focus on the spec.
>> >
>> > Appreciate input from the list. Please share if there are existing
>> efforts,
>> > relevant specs or use cases.
>> >
>> > ------------------------------
>> >
>> > A wallet interface specification for bitcoin applications
>> >
>> > ## Abstract
>> >
>> > This BIP describes an API for Bitcoin wallets and applications as a
>> > standard.
>> >
>> > ## Summary
>> >
>> > Bitcoin wallets should expose their address derivation and signing
>> > functions to external applications. The interface would be expressed as
>> > follows in javascript:
>> >
>> > ```
>> > {
>> > // Wallet Metadata
>> > wallet: {
>> > name: 'Bitcoin Core'
>> > },
>> >
>> > // Request access to the wallet for the current host
>> > async enable: (),
>> >
>> > // Request addresses and signatures from wallet
>> > async request ({ method, params })
>> > }
>> > ```
>> >
>> > In the web context the interface could be exposed at the top level of a
>> > webpage, for example under `window.bitcoin`. However this spec does not
>> > intend to define any standards for how and where the interfaces should
>> be
>> > exposed.
>> >
>> > ## Motivation
>> >
>> > Due to the seldom available APIs exposed by wallets, applications (web
>> or
>> > otherwise) are limited in how they are able to interact. Generally only
>> > simple sends have been available. A more robust API that introduces
>> other
>> > requests will promote richer Bitcoin applications.
>> >
>> > Additionally, wallet APIs have frequently included inconsistencies in
>> their
>> > interfaces and behaviour. This has required applications to build and
>> > maintain a separate client for each wallet, increasing the risk of bugs
>> and
>> > unintended behaviour as well as being a limiting factor for the
>> adoption of
>> > usable bitcoin applications.
>> >
>> > With a standardised wallet API:
>> >
>> > - Wallets have a clear API to implement
>> > - Applications have a clear expectation of wallet interface and
>> behaviour
>> > - Applications become agnostic to the wallet specifics, increasing
>> choice
>> > for users
>> >
>> > If more wallets implement the specification, applications will be
>> developed
>> > more confidently by benefiting from the wallet interoperability. This
>> > creates a positive feedback loop.
>> >
>> > ## Specification
>> >
>> > For simplicity, the interface is defined in the context of web
>> applications
>> > running in the browser (JS) however, they are simple enough to be easily
>> > implemented in other contexts.
>> >
>> > ### General Rules
>> >
>> > - For sensitive functions (e.g. signing), wallet software should always
>> > prompt the user for confirmation
>> >
>> > ### Types
>> >
>> > **UserDeniedError**
>> > An error type indicating that the application's request has been denied
>> by
>> > the user
>> > Type: Error
>> >
>> > **Hex**
>> > Type: String
>> > Example:
>> > `"0000000000000000000a24677957d1e50d70e67c513d220dbe8868c4c3aefc08"`
>> >
>> > **Address**
>> > Address details
>> > Type: Object
>> > Example:
>> >
>> > ```
>> > {
>> > "address": "bc1qn0fqlzamcfuahq6xuujrq08ex7e26agt20gexs",
>> > "publicKey":
>> > "02ad58c0dced71a236f4073c3b6f0ee27dde6fe96978e9a9c9500172e3f1886e5a",
>> > "derivationPath": "84'/1'/0'/0/0"
>> > }
>> > ```
>> >
>> > ### API
>> >
>> > The wallet must implement the following methods.
>> >
>> > **enable**
>> >
>> > The enable call prompts the user for access to the wallet.
>> >
>> > If successful, it resolves to an address (`**Address**` type) of the
>> > wallet. Typically the first external address to be used as an identity.
>> >
>> > **`UserDeniedError`** will be thrown if the request is rejected.
>> >
>> > **request**
>> >
>> > The request method must take one parameter in the following format:
>> >
>> > ```
>> > {
>> > "method": "wallet_methodName",
>> > "params": ["foo", "bar", "baz"]
>> > }
>> > ```
>> >
>> > For a list of mandatory methods see Table
>> >
>> > The wallet should reject request calls unless `enable` has been
>> resolved.
>> >
>> > Sensitive requests that involve signing should always prompt the user
>> for
>> > confirmation
>> >
>> > On success the request should resolve to the response as defined in the
>> > method table.
>> >
>> > **`UserDeniedError`** will be thrown if the request is rejected.
>> >
>> > **Mandatory methods**
>> >
>> > method: `wallet_getAddresses` params: [`index = 0, numAddresses = 1,
>> change
>> > = false`]
>> > return: `[ Address ]`
>> > error: UserDeniedError
>> >
>> > method: `wallet_signMessage` params: `[ message, address ]`
>> > return: Signature `Hex`
>> > error: UserDeniedError
>> >
>> > method: `wallet_signPSBT` params: `[ [psbtBase64, inputIndex, address]
>> ]`
>> > return: `psbtBase64`
>> > error: UserDeniedError
>> >
>> > method: `wallet_getConnectedNetwork` params: `[]`
>> > return: Network object `mainnet` | `testnet` | `regetst`
>> > error: UserDeniedError
>> >
>> > ## Rationale
>> >
>> > The purpose of the API is to expose a set of commonly used wallet
>> > operations. In addition, it should be flexible enough to serve for other
>> > requests such as node RPC calls.
>> >
>> > **Why is there a singular request call instead of named methods?**
>> > The transport layer for the requests cannot be assumed, therefore it is
>> > much more flexible to instead define an abstract format.
>> >
>> > **Why are the mandatory methods so primitive? Where is getBalance,
>> > getUtxos, ... ?**
>> > A wallet need not worry about providing every possible scenario for
>> usage.
>> > The primitives of keys and signing can expose enough to applications to
>> do
>> > the rest. Applications should have flexibility in how they implement
>> these
>> > functions. It is the role of a library rather than the wallet.
>> >
>> > ## Security Implications
>> >
>> > Great care should be taken when exposing wallet functionality
>> externally as
>> > the security and privacy of the user is at risk.
>> >
>> > ### Signing
>> >
>> > Operations that trigger signing using private keys should be guarded
>> behind
>> > confirmation screens where the user is fully aware of the nature of the
>> > transaction. In the example of a PSBT signature request, the outputs,
>> the
>> > inputs and which key is being used should be clearly marked.
>> >
>> > ### Privacy
>> >
>> > Some api methods expose metadata about the user, such as public keys.
>> > Depending on how privacy focused the wallet intends to be, the wallet
>> could
>> > protect these behind a confirmation. Commonly the wallet just needs to
>> give
>> > the origin access to all of its public keys, however it could also allow
>> > the option to expose only selected derivation paths.
>> >
>> > -monokh
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201223/3dbdb744/attachment-0001.html>

2023-06-07 18:17:38

- reply

📅 Original date posted:2019-04-08
📝 Original message:Mining strategy is like HFT profitable strategy, you keep it close if it’s
interesting, and you talk about it with the whole world if it’s void. gl.
On Sun, Apr 7, 2019 at 6:45 PM simondev1 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear bitcoin developers,
>
> New BIP: https://github.com/bitcoin/bips/pull/774
>
> ==Abstract==
> Logarithm of transaction fee limits block size.
>
> ==Motivation==
> Keep block space small.
> Waste less with spam transactions.
> Auto balance Fees: Increase very low fees, Descrease very high fees.
> Allow larger size when sender pays a lot.
> Allow wallets to calculate/display how much average free block space there
> is for each fee price.
> Allow senders to have more control about how the fee/priority of their
> transaction will behave, especially in the case of increased adoption in
> the future.
>
> ==Specification==
> Every transaction has to fit into the following block space:
> Input variable 'FeeInSatoshiPerByte': Must be positive or 0
> type: double
> unit: Satishi per byte
> Output:
> type: uint
> unit: bytes
> Formula:
> floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )
>
> ==Implementation==
> Sort transactions by FeeInSatoshiPerByte (lowest first)
> For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the
> bytes of space used so far. Check if summed up bytes of space used so far
> is smaller or equal than the formula result.
> If this is valid for each transaction then the blocksize is valid.
>
> ==Backward compatibility==
> Soft fork: If applied AND old hardcoded block size limit is kept.
> Hard fork: If applied AND old hardcoded block size limit is removed.
>
> Regards, simondev1
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190409/8753e479/attachment.html>

2023-06-07 18:17:27

- reply

📅 Original date posted:2019-04-14
📝 Original message:This sounds really promising to me, I think it could seriously improve the
current SPV trust model.
In abstract these are the possible setups today:
Full node: All history, 100% monetary sovereignty.
SPV: fancy term to Electrum trust model, random selection of nodes, with
full delegation of monetary responsibility.
I think in that spirit a hybrid approach of full node + spv.
As follows:
Hardware spv with only genesis hash block seeded, as a safe bootstrap, from
there only headers is needed for validation, and ongoing new fresh blocks
and associated historic blocks for conducting transactions.
On Wed, Apr 3, 2019 at 2:43 AM James O'Beirne via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I'd like to discuss assumeutxo, which is an appealing and simple
> optimization in the spirit of assumevalid[0].
>
> # Motivation
>
> To start a fully validating bitcoin client from scratch, that client
> currently
> needs to perform an initial block download. To the surprise of no one, IBD
> takes a linear amount time based on the length of the chain's history. For
> clients running on modest hardware under limited bandwidth constraints,
> say a mobile device, completing IBD takes a considerable amount of time
> and thus poses serious usability challenges.
>
> As a result, having fully validating clients run on such hardware is rare
> and
> basically unrealistic. Clients with even moderate resource constraints
> are encouraged to rely on the SPV trust model. Though we have promising
> improvements to existing SPV modes pending deployment[1], it's worth
> thinking about a mechanism that would allow such clients to use trust
> models closer to full validation.
>
> The subject of this mail is a proposal for a complementary alternative to
> SPV
> modes, and which is in the spirit of an existing default, `assumevalid`.
> It may
> help modest clients transact under a security model that closely resembles
> full validation within minutes instead of hours or days.
>
> # assumeutxo
>
> The basic idea is to allow nodes to initialize using a serialized version
> of the
> UTXO set rendered by another node at some predetermined height. The
> initializing node syncs the headers chain from the network, then obtains
> and
> loads one of these UTXO snapshots (i.e. a serialized version of the UTXO
> set
> bundled with the block header indicating its "base" and some other
> metadata).
>
> Based upon the snapshot, the node is able to quickly reconstruct its
> chainstate,
> and compares a hash of the resulting UTXO set to a preordained hash
> hard-coded
> in the software a la assumevalid. This all takes ~23 minutes, not
> accounting for
> download of the 3.2GB snapshot[2].
>
> The node then syncs to the network tip and afterwards begins a simultaneous
> background validation (i.e., a conventional IBD) up to the base height of
> the
> snapshot in order to achieve full validation. Crucially, even while the
> background validation is happening the node can validate incoming blocks
> and
> transact with the benefit of the full (assumed-valid) UTXO set.
>
> Snapshots could be obtained from multiple separate peers in the same
> manner as
> block download, but I haven't put much thought into this. In concept it
> doesn't
> matter too much where the snapshots come from since their validity is
> determined via content hash.
>
> # Security
>
> Obviously there are some security implications due consideration. While
> this
> proposal is in the spirit of assumevalid, practical attacks may become
> easier.
> Under assumevalid, a user can be tricked into transacting under a false
> history
> if an attacker convinces them to start bitcoind with a malicious
> `-assumevalid`
> parameter, sybils their node, and then feeds them a bogus chain
> encompassing
> all of the hard-coded checkpoints[3].
>
> The same attack is made easier in assumeutxo because, unlike in
> assumevalid,
> the attacker need not construct a valid PoW chain to get the victim's node
> into
> a false state; they simply need to get the user to accept a bad
> `-assumeutxo`
> parameter and then supply them an easily made UTXO snapshot containing,
> say, a
> false coin assignment.
>
> For this reason, I recommend that if we were to implement assumeutxo, we
> not
> allow its specification via commandline argument[4].
>
> Beyond this risk, I can't think of material differences in security
> relative to
> assumevalid, though I appeal to the list for help with this.
>
> # More fully validating clients
>
> A particularly exciting use-case for assumeutxo is the possibility of
> mobile
> devices functioning as fully validating nodes with access to the complete
> UTXO
> set (as an alternative to SPV models). The total resource burden needed to
> start a node
> from scratch based on a snapshot is, at time of writing, a ~(3.2GB
> + blocks_to_tip * 4MB) download and a few minutes of processing time,
> which sounds
> manageable for many mobile devices currently in use.
>
> A mobile user could initialize an assumed-valid bitcoin node within an
> hour,
> transact immediately, and complete a pruned full validation of their
> assumed-valid chain over the next few days, perhaps only doing the
> background
> IBD when their device has access to suitable high-bandwidth connections.
>
> If we end up implementing an accumulator-based UTXO scaling design[5][6]
> down
> the road, it's easy to imagine an analogous process that would allow very
> fast
> startup using an accumulator of a few kilobytes in lieu of a multi-GB
> snapshot.
>
> ---
>
> I've created a related issue at our Github repository here:
> https://github.com/bitcoin/bitcoin/issues/15605
>
> and have submitted a draft implementation of snapshot usage via RPC here:
> https://github.com/bitcoin/bitcoin/pull/15606
>
> I'd like to discuss here whether this is a good fit for Bitcoin
> conceptually. Concrete
> plans for deployment steps should be discussed in the Github issue, and
> after all
> that my implementation may be reviewed as a sketch of the specific software
> changes necessary.
>
> Regards,
> James
>
>
> [0]:
> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
> [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @
> 2.10GHz
> [3]:
> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
> [4]: Marco Falke is due credit for this point
> [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
> [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190414/49e2ee67/attachment-0001.html>

2023-06-07 18:17:17

- reply

📅 Original date posted:2019-03-31
📝 Original message:Shit, so we are vulnerable today? is this zero day vulnerability? so we
could be f***** big?
On Mon, Apr 1, 2019 at 5:47 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
>
> I believe I've found a serious vulnerability in your proposal: there's no
> limit
> on the maximum supply of USD.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190401/73e3c005/attachment.html>

2023-06-07 18:17:17

- reply

📅 Original date posted:2019-03-31
📝 Original message:Reasonable, I think also first timer should be forbidden form transacting
for at least 3 years from the first purchase, after going in '3 years' into
the rabbit hole, you can consider selling bitcoins. that's fair for low
time hard money folks, imho.
On Mon, Apr 1, 2019 at 3:33 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
>
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to
> the
> price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation
> of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency
> other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing,
> weight
> calculation, and so on, the output count must be incremented by one. Prior
> to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero,
> and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions.
> Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1),
> a
> block is reject as invalid unless all transactions it contains both
> declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at
> a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190401/30e360be/attachment-0001.html>

2023-06-07 18:17:11

- reply

📅 Original date posted:2019-03-20
📝 Original message:Also, quick question, is groups.io has same structure as Linux Foundation?
foundation/transparency/openness... I think in general it would be great if
this migration will be communicated much more in advance with relaxed
timelines, just by examining priori cases, it's all suggestions. hope next
phase will be more inclusive and open.
On Wed, Mar 20, 2019 at 2:45 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Mar 18, 2019 at 06:35:47PM -0400, Warren Togami Jr. via
> bitcoin-dev wrote:
> > The new archive will be operated independently outside from the Linux
> > Foundation as generated by this open source tool. This hopefully will
> allow
> > all future archives to never move again even if the underlying list
> > infrastructure needs to change. Folks will appreciate the search function
> > and git clone for a local instance.
>
> Where will that git archive actually be created/maintained? As this will
> be a
> Git repo, looks like getting it timestamped could be as simple as
> installing
> OpenTimestamps appropriately on whatever server is actually maintaining it.
>
> Equally, it'd be good to have the archive PGP signed.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190320/67fa0e4a/attachment.html>

2023-06-07 18:17:00

- reply

📅 Original date posted:2019-03-12
📝 Original message:Dear Gregory,
First of all, I would like to express my deep appreciation to your entire
craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
I think you are a brilliant engineer and very principled leader. your
efforts are an inspiration for many, a truly enduring forever mark in
history of FOSS.
I've submitted fixes to your concerns here:
https://github.com/bitcoin/bips/commit/b63ed0e17e872b7e7b8634591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff
Would appreciate your review.
On other note, I still think that this security fix is redundant, I believe
CKD function (BIP32) does encapsulate sufficient amount of entropy, but due
to lack of formal knowledge and assistance, I've not managed to get formal
proof, so I fallback'ed to add this patch for security reasons.
Best regards,
Omar
On Fri, Sep 1, 2017 at 10:16 AM Omar Shibli <omarshib at gmail.com> wrote:
> Hello Gregory,
>
> Thanks for you feedback.
>
> The BIP has been updated to explicitly specify the multiparty key
> derivation scheme which hopefully addresses your concerns.
>
> Please have a look at the updated draft of the BIP at the link below:
>
>
> https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
>
> Any feedback is highly appreciated.
>
> Regards,
> Omar
>
> On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib at gmail.com> wrote:
>
>> Thank you for your time Gregory, I really appreciate that.
>>
>> What we are describing here is a method to embed cryptographic signatures
>> into a public key based on HD Wallets - BIP32.
>> In a practical application, we should have two cryptographic signatures
>> from both sides, I don't think in that case your scenario would be an issue.
>>
>> More specifically in our application, we do the following construction:
>>
>> contract base: m/200'/0'/<contract_number>'
>> payment base (merchant commitment):
>> contract_base/<merchant_contract_signature>
>> payment address (customer commitment):
>> contract_base/<merchant_contract_signature>/<customer_contract_signature>
>>
>> payment address funds could be reclaimed only if the
>> customer_contract_signature is provided by the customer.
>>
>> In terms of durability, our app is pretty simple at this point, we don't
>> store anything, we let customer download and manage the files.
>>
>> I will update the BIP to address your concerns.
>>
>> On Tue, Aug 15, 2017 at 8:12 AM, Gregory Maxwell <greg at xiph.org> wrote:
>>
>>> This construction appears to me to be completely insecure.
>>>
>>>
>>> Say my pubkey (the result of the derivation path) is P.
>>>
>>> We agree to contract C1. A payment is made to P + G*H(C1).
>>>
>>> But in secret, I constructed contract C2 and pubkey Q and set P = Q +
>>> G*H(C2).
>>>
>>> Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
>>> it was in act a payment to P' + G*H(C2). (P' is simply Q + G*H(C1))
>>>
>>> I don't see anything in the proposal that addresses this. Am I missing
>>> it?
>>>
>>> The applications are also not clear to me, and it doesn't appear to
>>> address durability issues (how do you avoid losing your funds if you
>>> lose the exact contract?).
>>>
>>>
>>>
>>>
>>> On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > Hey all,
>>> >
>>> > A lot of us familiar with the pay to contract protocol, and how it uses
>>> > cleverly the homomorphic property of elliptic curve encryption system
>>> to
>>> > achieve it.
>>> > Unfortunately, there is no standard specification on how to conduct
>>> such
>>> > transactions in the cyberspace.
>>> >
>>> > We have developed a basic trade finance application that relies on the
>>> > original idea described in the Homomorphic Payment Addresses and the
>>> > Pay-to-Contract Protocol paper, yet we have generalized it and made it
>>> BIP43
>>> > complaint.
>>> >
>>> > We would like to share our method, and get your feedback about it,
>>> hopefully
>>> > this effort will result into a standard for the benefit of the
>>> community.
>>> >
>>> > Abstract idea:
>>> >
>>> > We define the following levels in BIP32 path.
>>> > m / purpose' / coin_type' / contract_id' / *
>>> >
>>> > contract_id is is an arbitrary number within the valid range of
>>> indices.
>>> >
>>> > Then we define, contract base as following prefix:
>>> > m / purpose' / coin_type' / contract_id'
>>> >
>>> > contract commitment address is computed as follows:
>>> > hash document using cryptographic hash function of your choice (e.g.
>>> blake2)
>>> > map hash to partial derivation path
>>> > Convert hash to binary array.
>>> > Partition the array into parts, each part length should be 16.
>>> > Convert each part to integer in decimal format.
>>> > Convert each integer to string.
>>> > Join all strings with slash `/`.
>>> > compute child public key by chaining the derivation path from step 2
>>> with
>>> > contract base:
>>> > m/<contract_base>/<hash_derivation_path>
>>> > compute address
>>> > Example:
>>> >
>>> > master private extended key:
>>> >
>>> xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
>>> > coin type: 0
>>> > contract id: 7777777
>>> >
>>> > contract base computation :
>>> >
>>> > derivation path:
>>> > m/999'/0'/7777777'
>>> > contract base public extended key:
>>> >
>>> xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>>> >
>>> > Contract content:
>>> > foo
>>> >
>>> > Contract sha256 signature:
>>> > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
>>> >
>>> > Contract partial derivation path:
>>> >
>>> 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> >
>>> > Contract commitment pub key path:
>>> >
>>> m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> > or
>>> >
>>> <contract_base_extended_pub_key>/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> >
>>> > Contract commitment pub key:
>>> >
>>> xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>>> >
>>> > Contract commitment address:
>>> > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>>> >
>>> >
>>> > You can find the full BIP draft in the following link:
>>> >
>>> https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
>>> >
>>> >
>>> > Regards,
>>> > Omar
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190312/e00eccc7/attachment-0001.html>

2023-06-07 18:06:28

- reply

📅 Original date posted:2017-09-29
📝 Original message:Thank you for sharing, this is indefinitely valuable.
I think that risk could be mitigated if instead of ignoring the bitcoin
address/amount/..., the wallet use this address for integrity checks.
Furthermore, I think this BIP could be improved by actually applying the
homomorphic property and deriving the bitcoin address from merchant pub key
and the hash itself. that would allow both the customer and merchant to be
able generate address independently.
On Fri, Sep 29, 2017 at 5:55 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev
> wrote:
> > Andreas Schildbach wrote:
> > > This feels redundant to me; the payment protocol already has an
> > > expiration time.
> >
> > The BIP-70 payment protocol has significant overhead and most
> importantly requires back and forth. Emailing a bitcoin address or printing
> it on an invoice is much easier, so I would expect people to keep doing
> that.
>
> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
> qr
> codes don't cryptographically commit to the identity of the merchant, which
> means a MITM attacker can redirect the payment if they can obtain a SSL
> cert
> that the wallet accepts.
>
> For example, if I have a wallet on my phone and go to pay a
> merchant, a BIP-72 URI will look like the following(1):
>
> bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://
> merchant.com/pay.php?h%3D2a8628fc2fbe
>
> A wallet following the BIP-72 standard will "ignore the bitcoin
> address/amount/label/message in the URI and instead fetch a PaymentRequest
> message and then follow the payment protocol, as described in BIP 70."
>
> So my phone will make a second connection - likely on a second network
> with a
> totally different set of MITM attackers - to https://merchant.com
>
> In short, while my browser may have gotten the correct URL with the correct
> Bitcoin address, by using the payment protocol my wallet is discarding that
> information and giving MITM attackers a second chance at redirecting my
> payment
> to them. That wallet is also likely using an off-the-shelf SSL library,
> with
> nothing other than an infrequently updated set of root certificates to use
> to
> verify the certificate; your browser has access to a whole host of better
> technologies, such as HSTS pinning, certificate transparency, and
> frequently
> updated root certificate lists with proper revocation (see Symantec).
>
> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
> supports a h= parameter with a hash commitment to what the payment request
> should be, and will reject the MITM attacker if that hash doesn't match.
> But
> that's not actually in the standard itself, and as far as I can tell has
> never
> been made into a BIP.
>
> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
> made
> to replace it.
>
> 1) As an aside, it's absolutely hilarious that this URL taken straight from
> BIP-72 has the merchant using PHP, given its truly terrible track
> record for
> security.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/4137a237/attachment-0001.html>

2023-06-07 18:06:14

- reply

📅 Original date posted:2017-09-26
📝 Original message:According to my understanding, Bitcoin protocol is a combination of several
components (node, miner, wallet..), you can use different licenses for
different components, as long as the components are well structured and
inter APIs are well defined and encapsulated, therefore, incompatible
licenses could be not an issue.
Please note that I'm not legal advisor and this is just my personal opinion.
On Tue, Sep 26, 2017 at 12:53 AM, Radcliffe, Mark via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My apologies if this post has been answered, but I am new to the list. I
> am lawyer trying to understand the licensing of the Bitcoin core and I
> will be presenting in a webinar with Black Duck Software on Blockchain on
> September 28 (in case you are not familiar with them, Black Duck Software
> assists companies in managing their open source software resources). They
> have scanned the Bitcoin Core code for the open source licenses used in the
> codebase. I am enclosing a summary of the findings. I would be interested
> in communicating with the individuals who manage this codebase and can
> provide insight about the project manages contributions because the
> codebase includes projects with inconsistent licenses (for example, code
> licensed under the Apache Software License version 2 and GPLv2 cannot work
> together in some situations). Thanks in advance.
>
>
>
> According to the scan, the code base includes code licensed under the
> following licenses:
>
>
>
> Apache License 2.0
>
> Boost Software License 1.0
>
> BSD 2-clause "Simplified" License
>
> BSD 3-clause "New" or "Revised" License
>
> Creative Commons Attribution Share Alike 3.0
>
> Expat License
>
> GNU General Public License v2.0 or later
>
> GNU General Public License v3.0 or later
>
> GNU Lesser General Public License v2.1 or later
>
> License for A fast alternative to the modulo reduction
>
> License for atomic by Timm Kosse
>
> MIT License
>
> Public Domain
>
> University of Illinois/NCSA Open Source License
>
>
>
>
>
>
>
>
>
> *Mark Radcliffe*
> Partner
>
>
> *T* +1 650.833.2266 <(650)%20833-2266>
> *F* +1 650.687.1222 <(650)%20687-1222>
> *M* +1 650.521.5039 <(650)%20521-5039>
> *E* mark.radcliffe at dlapiper.com
>
>
>
> [image: DLA Piper Logo]
>
>
>
> DLA Piper LLP (US)
> 2000 University Avenue
> East Palo Alto, California 94303-2215
> United States
> www.dlapiper.com
>
>
> Please consider the environment before printing this email.
>
> The information contained in this email may be confidential and/or legally
> privileged. It has been sent for the sole use of the intended recipient(s).
> If the reader of this message is not an intended recipient, you are hereby
> notified that any unauthorized review, use, disclosure, dissemination,
> distribution, or copying of this communication, or any of its contents, is
> strictly prohibited. If you have received this communication in error,
> please reply to the sender and destroy all copies of the message. To
> contact us directly, send to postmaster at dlapiper.com. Thank you.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170926/a58cc0c2/attachment.html>

2023-06-07 18:05:12

- reply

📅 Original date posted:2017-09-01
📝 Original message:Hello Gregory,
Thanks for you feedback.
The BIP has been updated to explicitly specify the multiparty key
derivation scheme which hopefully addresses your concerns.
Please have a look at the updated draft of the BIP at the link below:
https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
Any feedback is highly appreciated.
Regards,
Omar
On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib at gmail.com> wrote:
> Thank you for your time Gregory, I really appreciate that.
>
> What we are describing here is a method to embed cryptographic signatures
> into a public key based on HD Wallets - BIP32.
> In a practical application, we should have two cryptographic signatures
> from both sides, I don't think in that case your scenario would be an issue.
>
> More specifically in our application, we do the following construction:
>
> contract base: m/200'/0'/<contract_number>'
> payment base (merchant commitment): contract_base/<merchant_
> contract_signature>
> payment address (customer commitment): contract_base/<merchant_
> contract_signature>/<customer_contract_signature>
>
> payment address funds could be reclaimed only if the
> customer_contract_signature is provided by the customer.
>
> In terms of durability, our app is pretty simple at this point, we don't
> store anything, we let customer download and manage the files.
>
> I will update the BIP to address your concerns.
>
> On Tue, Aug 15, 2017 at 8:12 AM, Gregory Maxwell <greg at xiph.org> wrote:
>
>> This construction appears to me to be completely insecure.
>>
>>
>> Say my pubkey (the result of the derivation path) is P.
>>
>> We agree to contract C1. A payment is made to P + G*H(C1).
>>
>> But in secret, I constructed contract C2 and pubkey Q and set P = Q +
>> G*H(C2).
>>
>> Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
>> it was in act a payment to P' + G*H(C2). (P' is simply Q + G*H(C1))
>>
>> I don't see anything in the proposal that addresses this. Am I missing it?
>>
>> The applications are also not clear to me, and it doesn't appear to
>> address durability issues (how do you avoid losing your funds if you
>> lose the exact contract?).
>>
>>
>>
>>
>> On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Hey all,
>> >
>> > A lot of us familiar with the pay to contract protocol, and how it uses
>> > cleverly the homomorphic property of elliptic curve encryption system to
>> > achieve it.
>> > Unfortunately, there is no standard specification on how to conduct such
>> > transactions in the cyberspace.
>> >
>> > We have developed a basic trade finance application that relies on the
>> > original idea described in the Homomorphic Payment Addresses and the
>> > Pay-to-Contract Protocol paper, yet we have generalized it and made it
>> BIP43
>> > complaint.
>> >
>> > We would like to share our method, and get your feedback about it,
>> hopefully
>> > this effort will result into a standard for the benefit of the
>> community.
>> >
>> > Abstract idea:
>> >
>> > We define the following levels in BIP32 path.
>> > m / purpose' / coin_type' / contract_id' / *
>> >
>> > contract_id is is an arbitrary number within the valid range of indices.
>> >
>> > Then we define, contract base as following prefix:
>> > m / purpose' / coin_type' / contract_id'
>> >
>> > contract commitment address is computed as follows:
>> > hash document using cryptographic hash function of your choice (e.g.
>> blake2)
>> > map hash to partial derivation path
>> > Convert hash to binary array.
>> > Partition the array into parts, each part length should be 16.
>> > Convert each part to integer in decimal format.
>> > Convert each integer to string.
>> > Join all strings with slash `/`.
>> > compute child public key by chaining the derivation path from step 2
>> with
>> > contract base:
>> > m/<contract_base>/<hash_derivation_path>
>> > compute address
>> > Example:
>> >
>> > master private extended key:
>> > xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4Ux
>> FVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
>> > coin type: 0
>> > contract id: 7777777
>> >
>> > contract base computation :
>> >
>> > derivation path:
>> > m/999'/0'/7777777'
>> > contract base public extended key:
>> > xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnnii
>> D5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>> >
>> > Contract content:
>> > foo
>> >
>> > Contract sha256 signature:
>> > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
>> >
>> > Contract partial derivation path:
>> > 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25
>> 731/49056/63882/24200/25190/59310
>> >
>> > Contract commitment pub key path:
>> > m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/
>> 16692/4930/11632/25731/49056/63882/24200/25190/59310
>> > or
>> > <contract_base_extended_pub_key>/11302/46187/26879/50831/638
>> 99/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>> >
>> > Contract commitment pub key:
>> > xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj
>> 8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>> >
>> > Contract commitment address:
>> > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>> >
>> >
>> > You can find the full BIP draft in the following link:
>> > https://github.com/commerceblock/pay-to-contract-protocol-
>> specification/blob/master/bip-draft.mediawiki
>> >
>> >
>> > Regards,
>> > Omar
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/94a90deb/attachment.html>