<unnamed>

Public Key

npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrt

Profile Code

nprofile1qqswx95kvv5vfjmxcdr3nmu60vau2nhkq9nr449tqcv9nyfrwu665xgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmvsxlr0r

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 12:54:05 UTC

- reply

📅 Original date posted:2019-01-28
📝 Original message:
On Thu, 24 Jan 2019 at 13:42, René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Dear Melvin,
>
> I believe the vocabulary is not consistent across implementations. For
> example if you look at c lightning there is no such command `describegraph`
> but there are the two commands `listnodes` and `listchannels` which should
> give the same information. For both I have attached a sample output at the
> end of the mail to demonstrate how the naming of the vocabulary differs.
>
> Since the data of these commands is taken from the gossip store which
> stores the gossip messages I would suggest to take the vocabulary from the
> BOLT 07 which defines the gossip messages. Also this mailinglist is for
> protocol development and the spec should be the authorative source for
> naming:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>
> There are more terms specified in other bolts which could be a basis for a
> vocabulary. I have created an overview by hand and made a Pull Request to
> the repository which has not been merged yet as it was the wish of the
> developers to have such a list to be extracted automatically.
> Still this the overview in that pull request could serve as a basis for
> such a vocabulary :
> https://github.com/lightningnetwork/lightning-rfc/pull/458
>
> Now the example outputs from c-lightning we already that there are
> differences in naming. Take the identifier for a node for example:
> * BOLT07: node_id
> * LND: pub_key
> * clightning: nodeid
>
> example outputs:
>
> lighting-cli listnodes
> {
> "nodeid":
> "02396bf51e81f8f67eaca3652271b4fe8d3f57bedb9578af711606391c5c66760e",
> "alias": "PuraSloboda",
> "color": "68f442",
> "last_timestamp": 1548200218,
> "globalfeatures": "",
> "global_features": "",
> "addresses": [
> {
> "type": "ipv4",
> "address": "144.136.223.22",
> "port": 9735
> }
> ]
> }
>
> lightning-cli listchannels
> {
> "source":
> "03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d",
> "destination":
> "0272045af48b9871013753f7cce1cf82ed80b97d669ca44709e01976a67df80adc",
> "short_channel_id": "559893:1912:0",
> "public": true,
> "satoshis": 47000,
> "message_flags": 0,
> "channel_flags": 1,
> "flags": 1,
> "active": true,
> "last_update": 1548332847,
> "base_fee_millisatoshi": 1000,
> "fee_per_millionth": 1,
> "delay": 144
> }
>
> With kind regards Rene
>
This is extremely helpful, thank you!
I will go with the RFC naming then. I'm starting with Nodes and Edges and
will put together a document and demo for review. First step is to do
Nodes.
I have two questions
1. node_id -- that's basically your public key -- what types of key and
serialization is this (my guess an ecdsa pub key derived from the HD seed),
any pointers would be great
2. regarding the four address types :
- 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
- 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
- 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
- version 2 onion service addresses; Encodes an 80-bit, truncated
SHA-1 hash of a 1024-bit RSA public key for the onion service (a.k.a.
Tor hidden service).
- 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
- version 3 (prop224
<https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>)
onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] ||
[2:checksum] || [1:version], where checksum = sha3(".onion checksum"
| pubkey || version)[:2].
These can be looked up in the spec. But in the semantic web we like, where
possible, to have self describing data. In particular we like URIs with a
scheme or protocol so instead of example.com we'll have http://example.com
In this context would the scheme be lightning: for all 4 address types, or
is that just for bolt11?
>
> On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
>> wrote:
>>
>>> Dear Melvin,
>>>
>>> have you looked into the W3C Payment Group?
>>> https://www.w3.org/TR/payment-request/ The entire field of semantic web
>>> kind of originated from W3C and they are working on a recommendation for
>>> browser vendors to enable a low level payment API.
>>>
>>> Also there is LightningJoule that builds on top of webln. While this is
>>> not an otology it goes implicitly in a similar direction (c.f.:
>>> https://github.com/wbobeirne/webln and in particular this discussion:
>>> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
>>> his thoughts webln is different to the W3C Payment Group.)
>>>
>>> I am looking forward to see your progress with integrating Lightning to
>>> the semantic web!
>>>
>>> with kind regards Rene
>>>
>>
>> My first observation is these two data structures in lnd describe graph,
>> one for channels and one for nodes. These seem to be two fundamental
>> concepts in lightning.
>>
>> Channel
>>
>> {
>> "channel_id": "615605565348708353",
>> "chan_point":
>> "d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
>> "last_update": 1548330355,
>> "node1_pub":
>> "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
>> "node2_pub":
>> "03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
>> "capacity": "1000000",
>> "node1_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> },
>> "node2_policy": {
>> "time_lock_delta": 144,
>> "min_htlc": "1000",
>> "fee_base_msat": "1000",
>> "fee_rate_milli_msat": "1",
>> "disabled": false
>> }
>> }
>>
>> Node
>>
>> {
>> "last_update": 1547380072,
>> "pub_key":
>> "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
>> "alias": "OutaSpace",
>> "addresses": [
>> {
>> "network": "tcp",
>> "addr": "46.163.78.93:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
>> },
>> {
>> "network": "tcp",
>> "addr": "2dkobxxunnjatyph.onion:9760"
>> },
>> {
>> "network": "tcp",
>> "addr":
>> "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
>> }
>> ],
>> "color": "#123456"
>> },
>>
>> It would be useful to write a vocab for these and then document what they
>> mean. It would then be possible to add markup to an explorer to make it
>> self documenting.
>>
>> My first question is : are these terms consistent across different
>> implementations e.g. c-lightning, eclair ?
>>
>>
>>>
>>>
>>> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <
>>> melvincarvalho at gmail.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> I work on the solid project [1] and am very interested in the lightning
>>>> network.
>>>>
>>>> In particular, I am looking at trying to create an integration between
>>>> lightning (layer 2) and solid (layer 3? web layer?).
>>>>
>>>> The first step towards integration would be to port some of the
>>>> lightning concepts to the semantic web. This is done by creating an
>>>> ontology.
>>>>
>>>> Does anyone know of any existing work in this area. Alternatively,
>>>> does anyone have an interest to collaborate on an ontology?
>>>>
>>>> Best
>>>> Melvin
>>>>
>>>> [1] https://solid.mit.edu/
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>
>>>
>>> --
>>> https://www.rene-pickhardt.de
>>>
>>> Skype: rene.pickhardt
>>>
>>> mobile: +49 (0)176 5762 3618
>>>
>>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/0f8993e4/attachment-0001.html>

2023-06-09 12:54:04 UTC

- reply

📅 Original date posted:2019-01-22
📝 Original message:
On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Dear Melvin,
>
> have you looked into the W3C Payment Group?
> https://www.w3.org/TR/payment-request/ The entire field of semantic web
> kind of originated from W3C and they are working on a recommendation for
> browser vendors to enable a low level payment API.
>
Yes I have. Im a member of the community group. The working group is more
aligned to the shopping cart experience, but I'm trying to evangelize
lightning there too.
>
> Also there is LightningJoule that builds on top of webln.
>
I use it!
> While this is not an otology it goes implicitly in a similar direction
> (c.f.: https://github.com/wbobeirne/webln
>
Lovely, I will read
> and in particular this discussion:
> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
> his thoughts webln is different to the W3C Payment Group.)
>
Ditto!
I know the w3c folks pretty well. And we are talking about lightning more
and more.
>
> I am looking forward to see your progress with integrating Lightning to
> the semantic web!
>
Thanks!
>
> with kind regards Rene
>
>
>
> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>> Hi All
>>
>> I work on the solid project [1] and am very interested in the lightning
>> network.
>>
>> In particular, I am looking at trying to create an integration between
>> lightning (layer 2) and solid (layer 3? web layer?).
>>
>> The first step towards integration would be to port some of the lightning
>> concepts to the semantic web. This is done by creating an ontology.
>>
>> Does anyone know of any existing work in this area. Alternatively, does
>> anyone have an interest to collaborate on an ontology?
>>
>> Best
>> Melvin
>>
>> [1] https://solid.mit.edu/
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190122/6c50d852/attachment.html>

2023-06-09 12:54:04 UTC

- reply

📅 Original date posted:2019-01-24
📝 Original message:
On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
wrote:
> Dear Melvin,
>
> have you looked into the W3C Payment Group?
> https://www.w3.org/TR/payment-request/ The entire field of semantic web
> kind of originated from W3C and they are working on a recommendation for
> browser vendors to enable a low level payment API.
>
> Also there is LightningJoule that builds on top of webln. While this is
> not an otology it goes implicitly in a similar direction (c.f.:
> https://github.com/wbobeirne/webln and in particular this discussion:
> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
> his thoughts webln is different to the W3C Payment Group.)
>
> I am looking forward to see your progress with integrating Lightning to
> the semantic web!
>
> with kind regards Rene
>
My first observation is these two data structures in lnd describe graph,
one for channels and one for nodes. These seem to be two fundamental
concepts in lightning.
Channel
{
"channel_id": "615605565348708353",
"chan_point":
"d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
"last_update": 1548330355,
"node1_pub":
"024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
"node2_pub":
"03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
"capacity": "1000000",
"node1_policy": {
"time_lock_delta": 144,
"min_htlc": "1000",
"fee_base_msat": "1000",
"fee_rate_milli_msat": "1",
"disabled": false
},
"node2_policy": {
"time_lock_delta": 144,
"min_htlc": "1000",
"fee_base_msat": "1000",
"fee_rate_milli_msat": "1",
"disabled": false
}
}
Node
{
"last_update": 1547380072,
"pub_key":
"0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
"alias": "OutaSpace",
"addresses": [
{
"network": "tcp",
"addr": "46.163.78.93:9760"
},
{
"network": "tcp",
"addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
},
{
"network": "tcp",
"addr": "2dkobxxunnjatyph.onion:9760"
},
{
"network": "tcp",
"addr":
"nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
}
],
"color": "#123456"
},
It would be useful to write a vocab for these and then document what they
mean. It would then be possible to add markup to an explorer to make it
self documenting.
My first question is : are these terms consistent across different
implementations e.g. c-lightning, eclair ?
>
>
> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <melvincarvalho at gmail.com>
> wrote:
>
>> Hi All
>>
>> I work on the solid project [1] and am very interested in the lightning
>> network.
>>
>> In particular, I am looking at trying to create an integration between
>> lightning (layer 2) and solid (layer 3? web layer?).
>>
>> The first step towards integration would be to port some of the lightning
>> concepts to the semantic web. This is done by creating an ontology.
>>
>> Does anyone know of any existing work in this area. Alternatively, does
>> anyone have an interest to collaborate on an ontology?
>>
>> Best
>> Melvin
>>
>> [1] https://solid.mit.edu/
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
> --
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190124/aefe082a/attachment.html>

2023-06-09 12:54:03 UTC

- reply

📅 Original date posted:2019-01-21
📝 Original message:
Hi All
I work on the solid project [1] and am very interested in the lightning
network.
In particular, I am looking at trying to create an integration between
lightning (layer 2) and solid (layer 3? web layer?).
The first step towards integration would be to port some of the lightning
concepts to the semantic web. This is done by creating an ontology.
Does anyone know of any existing work in this area. Alternatively, does
anyone have an interest to collaborate on an ontology?
Best
Melvin
[1] https://solid.mit.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190121/0139602d/attachment.html>

2023-06-09 12:54:03 UTC

- reply

📅 Original date posted:2019-01-22
📝 Original message:
On Mon, 21 Jan 2019 at 11:08, Bretton Vine <bretton at hivemind.net> wrote:
> On 2019/01/21 08:17, Melvin Carvalho wrote:
> > The first step towards integration would be to port some of the lightning
> > concepts to the semantic web. This is done by creating an ontology.
>
> How do we do that? Build a list of relevant concepts and create possible
> attributes and links between? i.e.
>
Exactly! It's what is known as a vocabulary. You define terms and link
them to other terms.
Normally is starts from a use case, and then basically you come up with a
naming system that people agree on the names and store it somewhere.
>
> node
> pubkey
> ipaddress
> numberchannels
> channel
> stateactive/stateclosed
>
> channel
> fundingtx
> localbalance
> remotebalance
> closingfee
> stateopen/stateclosed
>
> fundingtx
> datetime
> amount
> fee
>
> transaction
> invoice
> amount
> destination
> validtime
>
> channelbreach
> datetime
> error
> result
>
Really good start, I'll try and go through these terms.
As I say, often we start with small common use cases then build up the set
of terms.
I have a couple of use cases in mind that others are interested in
1) sending satoshis to an inbox
2) the pay wall use case (like yalls) over ajax and maybe also on a normal
URL
>
> --
> regards, Bretton
> openpgp: http://bretton.hivemind.net/bretton_vine.asc
>
> _______________________________________________
> 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/20190122/5dd4baf1/attachment-0001.html>

2023-06-09 12:49:24 UTC

- reply

📅 Original date posted:2018-03-20
📝 Original message:
On 9 March 2018 at 05:28, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Corne,
>
> You mention URLs in your draft. This made me remember about the Web
> Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which
> Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/
> dbwg/details?group=83744&public=1
>
> My understanding is that Christian aims to make Bitcoin payments (and
> possibly Lightning invoice payments?) payable over Web payment protocols
> that W3C group is working on.
>
> Possibly the Web Payments Working Group may provide better perspective on
> various other payment use cases as well as their subtleties, which can help
> inform your considerations in your proposed BOLT12.
>
I'm interested in this effort too.
There's various levels of web payments incubation. Working Group is for
wide deployment in browsers. Interest Group is for ideas that are aimed at
standards track. Community group is aimed at new ideas and specs which can
have stable references, but may be more on the bleeding edge.
I do quite a bit of work with the W3C, so am happy to look over things, as
I'd like to include something similar in my apps. I was thinking I'd have
to make my own ontology, but if it's possible to reuse, that's even better!
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On March 8, 2018 11:19 PM, Corné Plooy via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> > Hi,
> >
> > I was thinking of how to use Lightning for various types of payments,
> >
> > and I think it's currently fine for customer/(web)shop type
> >
> > interactions, but it seems a bit inconvenient for other use cases, e.g.
> >
> > salary payments or direct pay-out of cryptocurrency bought on an
> >
> > exchange. I came up with an idea that addresses some of these issues and
> >
> > more (e.g. payee anonymity) by having a direct line of communication
> >
> > between payer and payee instead of BOLT11-style interaction. It's still
> >
> > a bit half-baked, with many details not worked out yet, but you can read
> >
> > it here, and see if you like where this is going:
> >
> > https://github.com/bitonic-cjp/lightning-rfc/blob/
> payment-protocol/12-payment-protocol.md
> >
> > In true permissionless fashion, I have been so bolD to register bolT #12
> >
> > for my idea.
> >
> > Please let me know what you think.
> >
> > kind regards,
> >
> > CJP
> >
> > 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/20180320/bf6c51a4/attachment-0001.html>

2023-06-07 22:52:11 UTC

- reply

📅 Original date posted:2021-04-27
📝 Original message:On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I endorse Harding's recommendations. On the point about mirroring,
> one thing to keep in mind is that the other repositories may go
> offline.
>
> Modification confusion could be avoided by recording what revision
> (commit hash) was current at the time of inclusion, but the document
> going offline can only be protected against by maintaining a copy
> somewhere.
>
One could partially solve the mirroring issue by giving each decentralized
BIP (optionally) a genesis transaction ID, that moved in time on the block
chain
This can be made to mirror / witness the evolution in git of the BIP using
git commit hashes (in time), and then matching those commit hashes in the
block chain by tweaking the public key address by the same amount (with no
change address)
What would occur then would be a genesis and current definitive HEAD of a
BIP, and the history it's gone through. The whole history can be
reconstructed from any one transaction. This is quite similar to Peter
Todd's single use seals, and the work done on RGB
Regarding commit trees going offline, they can be mirrored, hosted on
popular sites (github/gitlab) and it's natural that popular repos in git
are cloned
This also provides a little skin in the game and prevents some sybil
attacks, because you need to spend money on a TX
In this way whole BIPs can have a life cycle outside of any official body,
but also be assigned BIP numbers in the bitcoin repo
This mainly an informational idea, however, I have been working on some
code and early prototypes to do this, so feel free to message me off-list
if there's additional interest
>
>
> On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > > In general, I think its time we all agree the BIP process has simply
> failed
> > > and move on. Luckily its not really all that critical and proposed
> protocol
> > > documents can be placed nearly anywhere with the same effect.
> >
> > I recommend:
> >
> > 1. We add additional BIP editors, starting with Kalle Alm (if there are
> > no continuing significant objections).
> >
> > 2. We seek Luke Dashjr's resignation as BIPs editor.
> >
> > 3. We begin treating protocol documents outside the BIPs repository as
> > first-class BIP documentation.
> >
> > The first recommendation permits continued maintenance of existing BIPs
> > plus gives the additional maintainers an opportunity to rebuild the
> > credibility of the repository.
> >
> > The second recommendation addresses the dissatisfaction of many BIP
> > authors and potential authors with the current editor, which I think
> > will discourage many of them from making additional significant
> > contributions to the repository. It also seems to me to be a better use
> > of Luke's talents and interests for him to focus on protocol research
> > and review rather than procedurally checking whether a bunch of
> > documents are well formed.
> >
> > The third recommendation provides an escape hatch for anyone, such as
> > Matt, who currently thinks the process has failed, or for anyone who
> > comes to that same conclusion in the future under a different editing
> > team. My specific recommendations there are:
> >
> > a. Anyone writing protocol documentation in the spirit of the BIP
> > process can post their idea to this mailing list like we've always
> > done and, when they've finished collecting initial feedback, they can
> > assign themselves a unique decentralized identifier starting with
> > "bip-". They may also define a shorter alias that they encourage
> > people to use in cases where the correct document can be inferred
> > from context. E.g.,
> >
> > bip-wuille-taproot (bip-taproot)
> > bip-towns-versionbits-min-activation-height (bip-vbmah)
> > bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
> >
> > b. The author then publishes the document to any place they'd like,
> although
> > they are strongly encouraged to make any document source available
> > under an open license to ensure others can create their own
> > modifications.
> >
> > c. Implementations of BIPs, whether original repository BIPs or
> > decentralized BIPs, link to the BIPs they implement to ensure
> > researchers and developers can find the relevant protocol
> > documentation. E.g.,
> >
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
> >
> > (It may also be advisable for implementations to mirror copies of
> > the BIPs they implement so later modifications to the document
> > don't confuse anyone. For this reason, extremely liberal
> > licensing of BIP documents is encouraged.)
> >
> > d. To help maintain quality and consistency between documentation, the
> > BIP editors provide a BIP document template, guidelines similar to
> > the existing BIP2, and an easy-to-run format linter.
> >
> > I think this decentralized BIPs alternative also helps address some
> > longstanding problems with the BIPs system: that many casual Bitcoin
> > users and developers think of documents in the BIPs repo as
> > authoritative and that there are some development teams (such as for LN)
> > that have already abandoned the BIPs process because, in part, they want
> > complete control over their own documentation.
> >
> > The recommendations above were developed based on conversations I had
> > with a few stakeholders in the BIPs process, but I did not attempt a
> > comprehensive survey and I certainly don't claim to speak for anyone
> > else. I hope the recommendations are satisfactory and I look forward to
> > your feedback.
> >
> > Thanks,
> >
> > -Dave
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> 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/20210427/3e9db685/attachment-0001.html>

2023-06-07 15:26:50 UTC

- reply

📅 Original date posted:2014-10-25
📝 Original message:On 26 October 2014 00:10, Ross Nicoll <jrn at jrn.me.uk> wrote:
> I'd suggest looking at how Dogecoin's mining schedule has worked out, for
> how halvings tend to actually affect the market. Part of Dogecoin's design
> was that it would halve very quickly (around every 75 days, in fact), so
> it's essentially illustrating worst case scenario.
>
Yes that is an interesting data point, but it's really hard to find
comparables to doge, and most of its hashing is now merge mined with
litecoin. Comparing doge to btc may be a case of apples and oranges.
>
>
> Firstly, miners do not all move/shut down as a batch. Some will stay out
> of loyalty/apathy/optimism, so there's a jolt to hashrate when the rewards
> drop, and then a drift towards a steady-state. In most cases, the hardware
> costs vastly exceed the running costs, so while they may never see ROI due
> to the reward change, there's no benefit in stopping mining either.
>
> On the other side, mining hardware update cycles are extremely aggressive,
> and newer hardware runs much faster. Further, those with newer hardware are
> likely to have the best hashrate to power ratio, and be less likely to turn
> off or rent out their hardware.
>
> So, in theory there may be an uncomfortable period where the hashrate
> drops, but I would expect that drop to be much less than 50%, that most
> hardware that's turned off is not cost-effective to rent out, and that
> newer hardware being launched would push the hashrate back up again within
> a sensible timeframe.
>
> Ross
>
>
>
> On 25/10/2014 19:06, Alex Mizrahi wrote:
>
> # Death by halving
>
> ## Summary
>
> If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience
> catastrophic loss of hashpower (and, more importantly, catastrophic loss of
> security) after reward halving.
>
> ## A simple model
>
> Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
> total revenue miner receives over a period of time, and C_e is the cost of
> electricity spent on mining over the same period of time. (Note that for
> the sake of simplicity we do not take into account equipment costs,
> amortization and other costs mining might incur.)
>
> Also we will assume that transaction fees collected by miner are
> negligible as compared to the subsidy.
>
> Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
> halving and bitcoin and electricity prices stay the same, then mining is no
> longer profitable after the halving.
>
> Indeed, suppose the revenue after the halving is R' = R/2.
> MIM = (R-C_e)/R < 0.5
> R/2 < C_e.
>
> R' = R/2 < C_e.
>
> If revenue after halving R' doesn't cover electricity cost, a rational
> miner should stop mining, as it's cheaper to acquire bitcoins from the
> market.
>
> ~~~
>
> Under these assumptions, if the majority of miners have MIM less than
> 0.5, Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex model
> which takes into account changes in bitcoin price and difficulty changes
> over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
> ## Catastrophic loss of hashpower
>
> Bitcoin security model relies on assumption that a malicious actor
> cannot acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
> Spending_ paper which shows that as long as the malicious actor controls
> only a small fraction of total hashpower, attacks have well-define costs.
> But if the attacker-controlled hashrate is higher than 50%, attacks become
> virtually costless, as the attacker receives double-spending revenue on top
> of his mining revenue, and his risk is close to zero.
>
> Note that the simple model described in the aforementioned paper doesn't
> take into account attack's effect on the bitcoin price and the price of the
> Bitcoin mining equipment. I hope that one day we'll see more elaborate
> attack models, but in the meantime, we'll have to resort to hand-waving.
>
> Consider a situation where almost all available hashpower is available
> for a lease to the highest bidder on the open market. In this case someone
> who owns sufficient capital could easily pull off an attack.
>
> But why is hashpower not available on the market? Quite likely equipment
> owners are aware of the fact that such an attack would make Bitcoin
> useless, and thus worthless, which would also make their equipment
> worthless. Thus they prefer to do mining for a known mining pools with good
> track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
> particularly popular.)
>
> Now let's consider a situation where mining bitcoins is no longer
> profitable and the majority of hashpower became dormant, i.e. miners turned
> off their equipment or went to mine something else. In this case equipment
> is already nearly worthless, so people might as well lease it to the
> highest bidder, thus enabling aforementioned attacks.
>
> Alternatively, the attacker might buy obsolete mining equipment from
> people who are no longer interested in mining.
>
> ## Taking into account the Bitcoin price
>
> This is largely trivial, and thus is left as an exercise for the reader.
> Let's just note that the Bitcoin subsidy halving is an event which is known
> to market participants in advance, and thus it shouldn't result in
> significant changes of the Bitcoin price,
>
> ## Changes in difficulty
>
> Different mining devices have different efficiency. After the reward
> halving mining on some of these devices becomes unprofitable, thus they
> will drop out, which will result in a drop of mining difficulty.
>
> We can greatly simplify calculations if we sum costs and rewards across
> all miners, thus calculating average MIM before the halving: `MIM = 1 -
> C_e/R`.
>
> Let's consider an equilibrium break-even situation where unprofitable
> mining devices were turned off, thus resulting in the change in electricity
> expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
> 0`. In this case:
>
> r * C_e = R/2
> C_e / R = 1/2r
> (1 - MIM) = 1/2r
> r = 1/(2*(1-MIM))
>
> Let's evaluate this formulate for different before-halving MIM:
>
> 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can
> remain mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient
> miners consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs
> drop by 45%.
>
> We can note that for the before-halving MIM>0, r is higher than 1/2,
> thus less than half of total hashpower will drop out.
>
> The worst-case situation is when before-halving MIM is close to zero and
> mining devices, as well as cost of electricity in different places, are
> nearly identical, in that case approximately a half of all hashpower will
> drop out.
>
> ## MIM estimation
>
> OK, what MIM do we expect in the long run? Is it going to be less than
> 50% anyway?
>
> We can expect that people will keep buying mining devices as long as it
> is profitable.
>
> Break-even condition: `R - C_e - P = 0`, where P is the price of a
> mining device, R is the revenue it generates over its lifetime, and C_e is
> the total cost of required electricity over its lifetime. In this case, `R
> = C_e + P`, and thus:
>
> MIM = 1 - C_e / (C_e + P)
>
> `f = C_e / P` is a ratio of the cost of electricity to the cost of
> hardware, `C_e = f * P`, and thus
>
> MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
> MIM is less than 0.5 when f > 1.
>
> Computing f is somewhat challenging even for a concrete device, as it's
> useful lifetime is unknown.
>
> Let's do some guesstimation:
>
> Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If
> it's useful lifetime is more than 2 years and a cost of KWh is $0.1, the
> total expenditures on electricity will be at least $6135, thus for this
> device we have `f > 6135/4000 > 1.5`.
>
> If other devices which will be sold on the market will have similar
> specs, we will have MIM lower than 0.5. (Well, no shit.)
>
> ## Conclusions
>
> Reward halving is a deficiency in Bitcoin's design, but there is some
> hope it won't be critical: in the equilibrium break-even situation
> hashpower drop is less than 50%.
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141026/c5d1a032/attachment.html>

2023-06-07 15:26:46 UTC

- reply

📅 Original date posted:2014-10-25
📝 Original message:On 25 October 2014 21:53, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>
> We had a halving, and it was a non-event.
>> Is there some reason to believe next time will be different?
>>
>
> Yes.
>
> When the market is rapidly growing, margins can be relatively high because
> of limited amounts of capital being invested, or introduction of more
> efficient technologies.
>
> However, we should expect market to become more mature with time, and a
> mature market will result in lower margins.
> The halving can do much more damage when margins are relatively small.
>
> Besides that, there is a difference in ecosystem maturity:
>
> 1. Back in 2012, miners weren't so focused on profits, as Bitcoin was
> highly experimental: some were mining for the hell of it (it was a novelty
> thing back then), others wanted to secure the network, others did it
> because it was hard to obtain bitcoins by other means. But now miners are
> mostly profit-motivated: they buy expensive dedicated mining equipment and
> want to maximize profits. As you might know, at one point ghash.io
> reached 50% hashrate, and miners didn't care about it enough to switch to a
> different pool.
>
> 2. Back in 2012, we didn't have multipools. Multipools automatically
> switches between mining different alt-chains to maximize miners' profits.
> Miners who use multipools do not care how their hashrate is used as long as
> they profit off it.
> Particularly, check https://nicehash.com/ -- you can easily buy hashrate
> to attack a smaller alt-coin, for example.
>
> If the halving will result in a significant hashrate drop (and we did
> observe hashrate drop in 2012, although it wasn't that big), it might be
> possible to buy enough hashpower to attack Bitcoin.
>
This is a good point, imho. Miner sophistication has increased drastically
in 2 years. Sites like ( http://www.coinwarz.com/ ) can heavily influence
mining, 1-2 orders of magnitude on significant levels of hashing.
I think this is more prevalent with scrypt than sha256, litecoin is set to
half reward in 9 months, and it will be interesting to observe what happens
there.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/9e83bd0e/attachment.html>

2023-06-07 15:26:26 UTC

- reply

📅 Original date posted:2014-10-14
📝 Original message:FYI:
"In order to progress towards exit to Last Call for the Web Crypto API, the
chair suggests the following resolution for that bug.
resolution : Bug CLOSED. This problem will be addressed by the extension bug
25618 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618.
If none objects before the 20th of Oct @20:00 UTC, this resolution will be
endorsed."
On 13 October 2014 19:18, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> See-also: this related bug on Curve25519 and some MS Research curves
> that generated far more discussion.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
>
> Matt
>
> On 10/13/14 10:01, Melvin Carvalho wrote:
> > FYI:
> >
> > This is an issue I filed related to adding secp256k1 into Web Crypto API
> > which will be implemented natively in (some) web browsers.
> >
> > If there is any feedback from crypto implementers, please feel free to
> > add comments to this thread:
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444
> >
> > ---------- Forwarded message ----------
> > From: ** <bugzilla at jessica.w3.org <mailto:bugzilla at jessica.w3.org>>
> > Date: 13 October 2014 09:18
> > Subject: [Bug 24444] Named Curve Registry (adding secp256k1)
> > To: melvincarvalho at gmail.com <mailto:melvincarvalho at gmail.com>
> >
> >
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444
> >
> > Myron Davis <myrond at gmail.com <mailto:myrond at gmail.com>> changed:
> >
> > What |Removed |Added
> >
> ----------------------------------------------------------------------------
> > Status|RESOLVED |REOPENED
> > CC| |myrond at gmail.com
> > <mailto:myrond at gmail.com>
> > Resolution|NEEDSINFO |---
> >
> > --- Comment #2 from Myron Davis <myrond at gmail.com
> > <mailto:myrond at gmail.com>> ---
> > Could this be looked at again?
> >
> > Last response was waiting for feedback from crypto implementors.
> >
> > Currently secp256k1 is supported in the following SSL/TLS libraries now
> > Botan
> > NSS
> > openssl
> > LibreSSL
> > PolarSSL
> > JSSE
> >
> > The three other curves are all all have parameters which do not define
> > how they
> > were generated. secp256k1 curve has some great advantages in faster
> > signature
> > verification and how the values were determined for the curve. (i.e. not
> > random).
> >
> > http://www.ietf.org/rfc/rfc4492
> >
> > The curve has had a lot of eyes on it with lots of hardware and software
> > supporting this curve.
> >
> > With discovery of backdoor's in NIST's random number generator
> > (https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I
> > would
> > like to see a determined parameter curve instead of a "random" curve
> option.
> >
> > Thanks
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> > http://p.sf.net/sfu/Zoho
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141014/486b7876/attachment.html>

2023-06-07 15:26:25 UTC

- reply

📅 Original date posted:2014-10-13
📝 Original message:FYI:
This is an issue I filed related to adding secp256k1 into Web Crypto API
which will be implemented natively in (some) web browsers.
If there is any feedback from crypto implementers, please feel free to add
comments to this thread:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444
---------- Forwarded message ----------
From: <bugzilla at jessica.w3.org>
Date: 13 October 2014 09:18
Subject: [Bug 24444] Named Curve Registry (adding secp256k1)
To: melvincarvalho at gmail.com
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444
Myron Davis <myrond at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |myrond at gmail.com
Resolution|NEEDSINFO |---
--- Comment #2 from Myron Davis <myrond at gmail.com> ---
Could this be looked at again?
Last response was waiting for feedback from crypto implementors.
Currently secp256k1 is supported in the following SSL/TLS libraries now
Botan
NSS
openssl
LibreSSL
PolarSSL
JSSE
The three other curves are all all have parameters which do not define how
they
were generated. secp256k1 curve has some great advantages in faster
signature
verification and how the values were determined for the curve. (i.e. not
random).
http://www.ietf.org/rfc/rfc4492
The curve has had a lot of eyes on it with lots of hardware and software
supporting this curve.
With discovery of backdoor's in NIST's random number generator
(https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I
would
like to see a determined parameter curve instead of a "random" curve option.
Thanks
--
You are receiving this mail because:
You reported the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141013/92a06c56/attachment.html>

2023-06-07 15:25:45 UTC

- reply

📅 Original date posted:2014-09-15
📝 Original message:On 15 September 2014 09:23, Thomas Zander <thomas at thomaszander.se> wrote:
> On Sunday 14. September 2014 08.28.27 Peter Todd wrote:
> > Do we have any evidence Satoshi ever even had access to that key? Did he
> > ever use PGP at all for anything?
>
> Any and all PGP related howtos will tell you that you should not trust or
> sign
> a formerly-untrusted PGP (or GPG for that matter) key without seeing that
> person in real life, verifying their identity etc.
>
> I think that kind of disqualifies pgp for identity purposes wrt Satoshi :-)
>
But I presume that if the key is on bitcoin.org, you can probably infer
that the owner of the key and the original owner of bitcoin.org are one and
the same ...
>
> --
> Thomas Zander
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140915/bf82a94b/attachment.html>

2023-06-07 15:20:45 UTC

- reply

📅 Original date posted:2014-05-02
📝 Original message:On 14 November 2013 12:45, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> Rationale
> =======
>
> Given the recent rise in value there seems to be anecdotal evidence that 1
> bitcoin being so high is putting off a lot of normal buyers, because they
> feel that putting down $400+ and only getting "1 coin", or having to buy in
> multiples of 1 whole coin, is too much.. only after it being explained that
> they can buy fractional amounts to they regain interest, apparently
> happening increasingly.
>
>
> Straw Poll
> ========
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> ================
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown, for
> a total of 8 decimal places internally. It shows 1.00 but internally it's
> 1.00000000. If there's massive deflation in the future, the software could
> show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where the
> display shows the decimal point. Same amount of money, just different
> convention for where the ","'s and "."'s go. e.g. moving the decimal place
> 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software. Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?
>
>
Just a FYI on this topic. In Gavin's recent interview he described the
block reward as 25,000 millibits (about 25 minutes in).
https://www.youtube.com/watch?v=4pBd-OD9Rns
Decide for yourself whether or not that's meaningful :)
PS very enjoyable and accessible panel ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140502/aa705858/attachment.html>

2023-06-07 15:15:34 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 13 March 2014 16:50, Mike Hearn <mike at plan99.net> wrote:
> On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> Such hand-wavy, data-free logic is precisely why community
>> coordination is preferred to random apps making random decisions in
>> this manner.
>>
>
> That ship sailed months ago. If you wanted a big push for uBTC, then would
> have been the time. Though given that it'd have made lots of normal
> balances incredibly huge, perhaps it's a good thing that didn't happen.
> Also "milli" is a unit people encounter in daily life whereas micro isn't.
> Is it milli / micro / nano or milli / nano / micro? I bet a lot of people
> would get that wrong.
>
> If you have to export to financial packages that can't handle fractional
> pennies, then by all means represent prices in whatever units you like for
> that purpose, but in software designed for ordinary people in everyday life
> mBTC is a pretty good fit.
>
> Besides, fractional pennies crop up in existing currencies too (the famous
> Verizon Math episode showed this), so if a financial package insists on
> rounding to 2dp then I guess it may sometimes do the wrong thing in some
> business cases already.
>
> Fundamentally, more than two decimal places tends to violate the
>> Principle Of Least Astonishment with many humans, and as a result,
>> popular software systems have been written with that assumption.
>
>
> Lots of people use currencies that don't have any fractional components at
> all ! So perhaps all prices should be denominated in satoshis to ensure
> that they're not surprised :)
>
> The (number) line has to be drawn somewhere. Wallets are free to suppress
> more than 2dp of precision and actually Andreas' app lets you choose your
> preferred precision. So I think in the end it won't matter a whole lot, if
> the defaults end up being wrong people can change them until wallet authors
> catch up.
>
+1 agree with Mike on everything
A couple of points:
1. bitcoinity already switched to mbtc aka millitbits (
https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved, they
got quite a few donations
2. If you watch Gavin's talk at the CFR he suggests the community comes to
a consensus through implementations rather than top down decision making
(If I understood correctly)
I think it's up to wallet maintainers whether to switch the default.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/8d9f087b/attachment.html>

2023-06-07 15:11:25 UTC

- reply

📅 Original date posted:2014-01-03
📝 Original message:On 3 January 2014 06:22, Troy Benjegerdes <hozer at hozed.org> wrote:
> I believe this is self-explainatory:
>
> 1) Bitcoin usually runs on port 8333. Why?
>
> 2) Bitcoin does not show in up
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.. why?
>
> 3) What needs to happen to have someone from the Bitcoin foundation
> to fill out the form asking for an assigned port (see
> http://www.iana.org/form/ports-services )
>
> 4) what should the process be for new cryptocoins to get both default
> port numbers, as well as P2P network identifier 'magic numbers'
>
IANA normally register ports with the principle of conservation in mind.
See section 7.2 of RFC6335 for more details.
http://tools.ietf.org/html/rfc6335#section-7.2
8333 and 18333 are currently unassigned, which is good news.
Ideally it would be good to have two ports, one for the main net, and one
for the test net. However, in light of conservation only one may be
granted. The question as to whether traffic could be multiplexed over a
single port may be raised.
tnp 8321 udp Thin(ium) Network Protocol
[Aly_Orady] [Aly_Orady]
2007-08-07
8322-8350 Unassigned
server-find 8351 tcp Server Find
[Chris_Brown] [Chris_Brown]
gv-pf 18262 udp GV NetConfig Service
[Scott_Libert] [Scott_Libert]
2008-01-29
18263-18462 Unassigned
ac-cluster 18463 tcp AC Cluster
[Lisa_Zhong]
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
If a whole slew of alt coins also tried to reserve ports, I suspect that
may raise eyebrows.
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/3a0f63e9/attachment.html>

2023-06-07 15:09:30 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:Rationale
=======
Given the recent rise in value there seems to be anecdotal evidence that 1
bitcoin being so high is putting off a lot of normal buyers, because they
feel that putting down $400+ and only getting "1 coin", or having to buy in
multiples of 1 whole coin, is too much.. only after it being explained that
they can buy fractional amounts to they regain interest, apparently
happening increasingly.
Straw Poll
========
6 months ago there was a straw poll on this
https://bitcointalk.org/index.php?topic=220322.0
Roughly 2/3 of respondents favoured switching
A further 20% said to switch after it hits 1000
Satoshi's comments:
================
Eventually at most only 21 million coins for 6.8 billion people in the
world if it really gets huge.
But don't worry, there are another 6 decimal places that aren't shown, for
a total of 8 decimal places internally. It shows 1.00 but internally it's
1.00000000. If there's massive deflation in the future, the software could
show more decimal places.
If it gets tiresome working with small numbers, we could change where the
display shows the decimal point. Same amount of money, just different
convention for where the ","'s and "."'s go. e.g. moving the decimal place
3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.
https://bitcointalk.org/index.php?topic=44.msg267#msg267
Would now be a good time to start thinking about changing the default
display in the software. Perhaps initially it could be a dropdown display
option, then at some point mbtc becomes the default?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/264b078a/attachment.html>

2023-06-07 15:08:26 UTC

- reply

📅 Original date posted:2013-11-02
📝 Original message:On 2 November 2013 17:26, Mike Hearn <mike at plan99.net> wrote:
> Guys, identity systems for the web are off-topic for this list. Other than
> the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any
> relevance to it.
>
> On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo <hannu.kotipalo at iki.fi>wrote:
>
>> Maybe this is a bit off-topic, but the *real* answer to the question
>> "why-is-nobody-using-ssl-client-certificates" is that it would force
>> www pages to be encrypted and would make it a lot more difficult for
>> NSA to log www-trafic.
>>
>
> No, it wouldn't. You can log a user in using SSL and then redirect the
> user back to an encrypted page, using cookies for the rest of the session.
> Please don't clutter up this list with conspiracy theories. The brutal
> reality is that identity is a hard problem.
>
Identity need not be a hard problem. In my view it is a solved problem.
You have a real world entity translated to a digital format. Yes that can
be slightly ambiguous at time, naming is hard, and people do get this wrong
frequently.
The most common problem is to name something in a way that does not scale.
The solution to this problem is rather easy, and that is to use a URI to
name something, which makes it global and scalable.
In the case of bitcoin you could have use the bitcion URI scheme
bitcion:1fhdjkfhjksf...
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/502938fc/attachment.html>

2023-06-07 15:08:25 UTC

- reply

📅 Original date posted:2013-11-02
📝 Original message:On 2 November 2013 14:02, Mike Hearn <mike at plan99.net> wrote:
> On Sat, Nov 2, 2013 at 6:01 AM, <bitcoingrant at gmx.com> wrote:
>
>> In brief, the authentication work as follows:
>>
>>
>>
>> Server provides a token for the client to sign.
>>
>> client passes the signed message and the bitcoin address back to the
>> server.
>>
>> server validates the message and honors the alias (optional) and bitcoin
>> address as identification.
>>
>
> http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/
>
I actually use client certificates for almost all of my authentication.
It's true that the browser manufacturers have created an UX which is not
ideal, and very little effort is made to improve it. But it is possible.
See this project from Mozilla labs.
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
Unfortunately this got killed :(
More popular is the trusted third party model like OAuth or Persona.
There's a conflict of interest as well, because browser manufacturers are
often identity providers too, so there is an incentive to push TTP
technology.
There's two elements here. One is paswordless login (which I love). The
other is who controls your identity. I like to control my own identity (in
my browser) using PKI. But facebook and the big webmail providers have a
lions share of the market.
The way to shift the balance is to offer the right incentives.
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/1aaf3dcc/attachment.html>

2023-06-07 15:07:38 UTC

- reply

📅 Original date posted:2013-10-21
📝 Original message:On 21 October 2013 09:03, Martin Sustrik <sustrik at 250bpm.com> wrote:
> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> > How about putting them into sub directories that map onto the status of
> the BIP?
> >
> > Reading BIP 1, that would make:
> >
> > Accepted
> > Active
> > Draft
> > Deferred
> > Final
> > Rejected
> > Replaced
> > Withdrawn
>
> Have it been considered to do this via IETF? The process there is
> hardened by 40 years of experience and 7000+ RFCs. Probably better than
> anything you can devise yourself.
>
IETF is great for some things. I think the bitcoin URI scheme is being
registered with them.
However the process can take many years to get to an RFC, for something
relatively simple, not to mention there can be costs too
Given that crypto currencies are a relatively new field, I am unsure the
IETF has a wealth of expertise in this area, compared with the core devs
Maybe IETF is better to standardize some of the communications or
serialization components, but not so much the BIPs. Or perhaps some of the
BIPs can be written up as "Informational" rather than "Proposed Standard"
in the RFC format, and reviewed
I've followed quite a few FLOSS projects over the years. Overall, I've
been amazingly impressed with the BIP process (dont forget it's used in
other systems too -- python?). It seems an agile process, that strikes an
great balance between needed features, and documentation. I think that's
exactly what will continue bitcoin's momentum in the short to medium term.
>
> Martin
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131021/1b8fd110/attachment.html>

2023-06-07 15:07:32 UTC

- reply

📅 Original date posted:2013-10-19
📝 Original message:On 19 October 2013 18:38, Mitar <mmitar at gmail.com> wrote:
> Hi!
>
> Interesting read:
>
>
> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
>
Im sympathetic to some of the points, but it seems slightly harsh. I do
agree that we're lucky to have the excellent leadership of Gavin, who I
think is a great role model.
Perhaps the bitcoin community is at a size where it may benefit from a
loose code of conduct. The ubuntu code of conduct has been excellent in
this respect, in helping to grow that community:
http://www.ubuntu.com/about/about-ubuntu/conduct
[[
Ubuntu Code of Conduct v2.0
Community
Ubuntu is about showing humanity to one another: the word itself captures
the spirit of being human.
We want a productive, happy and agile community that can welcome new ideas
in a complex field, improve every process every year, and foster
collaboration between groups with very different needs, interests and
skills.
We gain strength from diversity, and actively seek participation from those
who enhance it. This code of conduct exists to ensure that diverse groups
collaborate to mutual advantage and enjoyment. We will challenge prejudice
that could jeopardise the participation of any person in the project.
The Code of Conduct governs how we behave in public or in private whenever
the project will be judged by our actions. We expect it to be honored by
everyone who represents the project officially or informally, claims
affiliation with the project, or participates directly.
We strive to:
Be considerate
Our work will be used by other people, and we in turn will depend on the
work of others. Any decision we take will affect users and colleagues, and
we should consider them when making decisions.
Be respectful
Disagreement is no excuse for poor manners. We work together to resolve
conflict, assume good intentions and do our best to act in an empathic
fashion. We don't allow frustration to turn into a personal attack. A
community where people feel uncomfortable or threatened is not a productive
one.
Take responsibility for our words and our actions
We can all make mistakes; when we do, we take responsibility for them. If
someone has been harmed or offended, we listen carefully and respectfully,
and work to right the wrong.
Be collaborative
What we produce is a complex whole made of many parts, it is the sum of
many dreams. Collaboration between teams that each have their own goal and
vision is essential; for the whole to be more than the sum of its parts,
each part must make an effort to understand the whole.
Collaboration reduces redundancy and improves the quality of our work.
Internally and externally, we celebrate good collaboration. Wherever
possible, we work closely with upstream projects and others in the free
software community to coordinate our efforts. We prefer to work
transparently and involve interested parties as early as possible.
Value decisiveness, clarity and consensus
Disagreements, social and technical, are normal, but we do not allow them
to persist and fester leaving others uncertain of the agreed direction.
We expect participants in the project to resolve disagreements
constructively. When they cannot, we escalate the matter to structures with
designated leaders to arbitrate and provide clarity and direction.
Ask for help when unsure
Nobody is expected to be perfect in this community. Asking questions early
avoids many problems later, so questions are encouraged, though they may be
directed to the appropriate forum. Those who are asked should be responsive
and helpful.
Step down considerately
When somebody leaves or disengages from the project, we ask that they do so
in a way that minimises disruption to the project. They should tell people
they are leaving and take the proper steps to ensure that others can pick
up where they left off.
Leadership, authority and responsibility
We all lead by example, in debate and in action. We encourage new
participants to feel empowered to lead, to take action, and to experiment
when they feel innovation could improve the project. Leadership can be
exercised by anyone simply by taking action, there is no need to wait for
recognition when the opportunity to lead presents itself.
Delegation from the top
Responsibility for the project starts with the "benevolent dictator", who
delegates specific responsibilities and the corresponding authority to a
series of teams, councils and individuals, starting with the Community
Council ("CC"). That Council or its delegated representative will arbitrate
in any dispute.
We are a meritocracy; we delegate decision making, governance and
leadership from senior bodies to the most able and engaged candidates.
Support for delegation is measured
Nominations to the boards and councils are at the discretion of the
Community Council, however the Community Council will seek the input of the
community before confirming appointments.
Leadership is not an award, right, or title; it is a privilege, a
responsibility and a mandate. A leader will only retain their authority as
long as they retain the support of those who delegated that authority to
them.
We value discussion, data and decisiveness
We gather opinions, data and commitments from concerned parties before
taking a decision. We expect leaders to help teams come to a decision in a
reasonable time, to seek guidance or be willing to take the decision
themselves when consensus is lacking, and to take responsibility for
implementation.
The poorest decision of all is no decision: clarity of direction has value
in itself. Sometimes all the data are not available, or consensus is
elusive. A decision must still be made. There is no guarantee of a perfect
decision every time - we prefer to err, learn, and err less in future than
to postpone action indefinitely.
We recognise that the project works better when we trust the teams closest
to a problem to make the decision for the project. If we learn of a
decision that we disagree with, we can engage the relevant team to find
common ground, and failing that, we have a governance structure that can
review the decision. Ultimately, if a decision has been taken by the people
responsible for it, and is supported by the project governance, it will
stand. None of us expects to agree with every decision, and we value highly
the willingness to stand by the project and help it deliver even on the
occasions when we ourselves may prefer a different route.
Open meritocracy
We invite anybody, from any company, to participate in any aspect of the
project. Our community is open, and any responsibility can be carried by
any contributor who demonstrates the required capacity and competence.
Teamwork
A leader's foremost goal is the success of the team.
"A virtuoso is judged by their actions; a leader is judged by the actions
of their team." A leader knows when to act and when to step back. They know
when to delegate work, and when to take it upon themselves.
Credit
A good leader does not seek the limelight, but celebrates team members for
the work they do. Leaders may be more visible than members of the team,
good ones use that visibility to highlight the great work of others.
Courage and considerateness
Leadership occasionally requires bold decisions that will not be widely
understood, consensual or popular. We value the courage to take such
decisions, because they enable the project as a whole to move forward
faster than we could if we required complete consensus. Nevertheless,
boldness demands considerateness; take bold decisions, but do so mindful of
the challenges they present for others, and work to soften the impact of
those decisions on them. Communicating changes and their reasoning clearly
and early on is as important as the implementation of the change itself.
Conflicts of interest
We expect leaders to be aware when they are conflicted due to employment or
other projects they are involved in, and abstain or delegate decisions that
may be seen to be self-interested. We expect that everyone who participates
in the project does so with the goal of making life better for its users.
When in doubt, ask for a second opinion. Perceived conflicts of interest
are important to address; as a leader, act to ensure that decisions are
credible even if they must occasionally be unpopular, difficult or
favourable to the interests of one group over another.
This Code is not exhaustive or complete. It is not a rulebook; it serves to
distill our common understanding of a collaborative, shared environment and
goals. We expect it to be followed in spirit as much as in the letter.
The Ubuntu Code of Conduct is licensed under the Creative Commons
Attribution-Share Alike 3.0 license. You may re-use it for your own
project, and modify it as you wish, just please allow others to use your
modifications and give credit to the Ubuntu Project!
]]
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131019/c6a2e96a/attachment.html>

2023-06-07 15:05:59 UTC

- reply

📅 Original date posted:2013-08-16
📝 Original message:On 16 August 2013 03:00, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded fees. I
> was busy today generating scatter-plots and histograms of transaction fees
> versus priorities to get some insight into what miner policies look like
> right now.
>
+1
>
> 2) "First double-spend" relaying and alerting, to better support low-value
> in-person transactions. Related:
> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>
>
>
+1
>
> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
> block size limit, how we can do it safely, and go through all of the
> arguments that have been made against it and explain why they're wrong.
>
What block size do you think is ideal?
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/2b19dc93/attachment.html>

2023-06-07 15:03:28 UTC

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 18 June 2013 05:48, Alan Reiner <etotheipi at gmail.com> wrote:
> *Goal*: An alternative address format made possible by BIP 32, which
> allows one to specify a "Wallet ID" and "One-time payment" code, instead of
> the standard one-use Base58-Hash160 addresses. This allows parties with a
> persistent relationship to be able to prove that payment addresses they
> provide each other are linked to a particular wallet, reducing exposure to
> MitM attacks without the need for SSL or a web of trust, and without
> compromising the privacy of either party. For instance, this could be
> used between businesses that frequently do business, by exchanging and
> verifying public keys beforehand, or could be used by an exchange to
> identify if a customer withdrawal address is related to their last deposit
> address, and if not enforce extra authentication measures.
>
> *Background**:*
> I haven't been following the payment protocol discussions/development
> much, so I apologize if this has already been addressed. I'm calling it
> "wallet-linkable" addresses, which would be an optional second form for
> sending someone your address. With BIP 32, the address is computed by the
> payee (the person sending the address to receive money):
>
> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i])
> || checksum)
>
> What I'd like to do is have the option, when specifying an address through
> the payment protocol, to send *just* the {PublicKeyParent, Multiplier[i]}
> and let the receiver of that address compute the address on their own.
> This is no significant burden on the receiver, but it does provide the
> useful property that they can recognize when addresses specified in this
> way come from the same wallet -- because the PubKeyParent will be the
> same. Remember, this is *optional* for the person providing the address.
>
> One nice, accidental feature of BIP 32 is that the Multiplier[i] used
> above does not actually reveal the "chaincode" (I think Pieter started
> calling it the "tweak"). It is derived from the chaincode but doesn't
> reveal it. Therefore, the payer sees the parent public key, but that's not
> useful to derive any of the other addresses unless they also have the
> chaincode. But they can verify that the PublicKeyParent is identical
> between transactions, and thus is accessible only to that wallet. It
> allows them validate a specific address provided by the payee, but not
> generate or identify any other addresses.
>
> *Use Cases:*
> (1) So, just like with PGP/GPG, when two parties decide they will start a
> relationship, they can start by exchanging the public keys of their wallet
> and verify them in a reliable manner. After that, when one party requests
> a payment address from the other, they can optionally send {PubKey,
> Multiplier}, and the payer's software will identify the owner of that
> address, or let you select who you think the address belongs to and it will
> verify it. If the payee's system is compromised and address is replaced,
> the address received by the payer won't validate. This doesn't help if the
> side sending the money is compromised.
>
> (2) When a customer first provides a deposit to an exchange, it will send
> money from an address in their wallet and the software will provide the
> exchange the {PubKey,Mult}. When the customer later provides a withdrawal
> address, the site can automatically trust the address as long it is
> provided in the alternate form and the public keys match. If they don't,
> it might be the same customer just requesting a withdrawal to a different
> wallet, which is fine, but they'll have to go through an extra verification
> step to do so.
>
>
> *Downsides:*
> Multi-sig/P2SH - The only way this works with P2SH, violates one of the
> goals of P2SH slightly, but may not matter much if it's all done under the
> hood by the software. Instead of providing a 20-byte hash of a script, you
> provide all the public keys and multipliers for the individual addresses.
> The payer's software automatically verifies all addresses and creates the
> P2SH script itself (after a divine decree that public keys will always be
> sorted lexicographically in the multi-sig script). The blockchain still
> benefits from the "compression" of moving the bulky scripts to the TxIn,
> but it does require revealing more information than is necessary for the
> payer to pay the payee. But it may not *really* be a problem, given the
> benefits. It might just be slightly longer strings to exchange during
> initialization and for each transaction.
>
> I have various reasons I'd like to use this, and it'd be nice to have some
> community backing, so I don't have to twist anyone's arm to trust me that
> it's legit.
>
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be less
keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar with the material than some. However, there's
little things like it never actually defines a deterministic wallet in the
Abstract. But, I'll keep trying to understand and see if I can use the
test vectors.
>
> -Alan
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/c32fc5bc/attachment.html>

2023-06-07 15:03:06 UTC

- reply

📅 Original date posted:2013-06-10
📝 Original message:On 10 June 2013 10:35, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
> > However, Bitcoin's fundamental philosophy was one CPU one vote.
>
> This is perhaps the largest misconception that keeps being repeated.
> Bitcoin is not a democracy; it is a zero-trust system. The rules are
> set in stone, and every full node verifies all rules and must
> independently come to the same result as everyone else. Obviously, if
> everyone changes their software, anything can change, but from within
> the system there is no way to change which blocks are considered
> valid, and there is certainly no voting mechanism about that.
>
> What is voted about, is the one single thing that cannot be decided by
> each node individually: namely the order of otherwise valid and
> non-conflicting transactions, and that's just because it's a
> necessity. Because deciding the order includes delaying transaction
> potentially indefinitely, a majority of miners can indeed choose the
> enforce an additional rule about which transactions are considered
> valid, but the rules implemented in full nodes do not change without
> changing the software. For example, miners cannot decide to raise the
> block subsidy, even if every single miner out there would want that.
> They'd just end up being ignored by everyone else.
>
> > Voting is easily gamed. While this may work in one particular case, it
> is
> > perhaps a bad precedent to set. Establishing methods of voting can lead
> to
> > single points of failure.
>
> The problem is that at some point, you have to look at the system from
> a higher level than just the technical part. And because ultimately
> the possibility exists where everyone changes their software, and
> there is an exceedingly high incentive for consensus (a deliberate
> hard-fork where two groups of users decide to use different and
> incompatible rules, aware of eachother, is suicide for the system, in
> my opinion). This results in the fact that proposed changes can indeed
> become new adopted hard rules in the system, and I don't think there's
> anything that can be done about it. Bitcoin is a consensus system - at
> the technical level - but also a consensus of the people using it, and
> ultimately they decide the rules.
>
OK I accept that the timestamping is one CPU one vote. However rule
changes seem rather arbitrary.
Towit if you use a voting/consensus system and want to destroy bitcion it
seems quite easy.
Iterate on picking a rule chance that will divide the consensus in such a
way as to create ensuing chaos.
I think voting is too easy gamed for it it to be meaningful other than a
straw poll.
If there's a bug, and everyone is unanimous that it's a bug, it can be
fixed.
If there's a controversial rule change, we should be extremely cautious and
not do it unless there's a very good reason. Keeping to satoshi's model as
much as possible without introducing human factors, unnecessarily.
>
>
> > Unless there's a very good reason not to, e.g. miners are clearly abusing
> > the system, we should stick with 1 CPU one vote.
>
> So you're saying that instead of a zero-trust system, we should move
> to a system where miners can decide _everything_ - as opposed to just
> being in charge of ordering transactions? I don't think you understand
> the system at all, if that is what you're proposing.
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130610/7686b617/attachment.html>

2023-06-07 15:03:05 UTC

- reply

📅 Original date posted:2013-06-10
📝 Original message:On 10 June 2013 10:26, John Dillon <john.dillon892 at googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
> > -1
> >
> > Firstly I appreciate the ingenious thought that went into this post.
> >
> > However, Bitcoin's fundamental philosophy was one CPU one vote.
>
> Indeed it was. Which is why as GPU's came onto the scene Satoshi was
> strongly
> against them. I have to wonder what he thinks of ASICs where just a
> handful of
> companies control the supply of Bitcoin hashing power.
>
Thanks for your reply. Do you have a pointer to Satoshi being strongly
against GPU? I'd be interested to see that. FWIW, I've read all his forum
posts a few times, I just dont recall this one, tho I'm sure it's there...
>
> Satoshi also never forsaw pools, which are why just 2 or 3 people control
> the
> majority of Bitcoin hashing power.
>
> > The asymmetry lies in psychological terms, in that new defaults tend to
> be
> > adopted 80% of the time, so core devs have disproportionate amount of
> power
> > as things stand.
>
> That's why I'm very clear that doing nothing is a vote for the status quo.
> Of
> course wallet authors can do what they want to try to get users to vote
> according to their wishes, or for that matter simply steal your vote, but
> we
> already must put a lot of faith into wallets to not steal our funds.
>
> > Unless there's a very good reason not to, e.g. miners are clearly abusing
> > the system, we should stick with 1 CPU one vote.
>
> People are proposing we put control of the blocksize entirely into the
> hands of
> miners, yet we all have an interest in auditing the blocks miners produce.
> There must be balance.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRtY2jAAoJEEWCsU4mNhiPQEsH/0VNA7aJYdUbJjTnIiKoaCv3
> JtWS1MKHjAJE6ZPDt+T/QPkEdZI4kNz3DGcZL6EDJtvZxZHfvEIaZDF1gpaH6OkC
> oIZ0PkFPOxi0cncuAvT/a770evu7LzuT6fisY3EgGnlHujLQZ47LEa73Xo7pJVc7
> RJHamGwkj+3HZRIuZIAn87qws/zRyTx5SXvb56xCKb0oxE4ZO0dn+8/nNSPWw13i
> p3LpLlEQBBu+Du2nPSQupRjkz4MPP8v9EYefV5cjtNBK7ufAvA64OnwKB5dST+h+
> N/vBcj3EIj/WEOf4myGcVxKp+skJ2SJDwxLigevgkKYPDNTVfXIverdXB0ANrQA=
> =c8iU
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130610/d2971bec/attachment.html>

2023-06-07 15:03:03 UTC

- reply

📅 Original date posted:2013-06-10
📝 Original message:On 10 June 2013 06:09, John Dillon <john.dillon892 at googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> It has been suggested that we leave the decision of what the blocksize to
> be
> entirely up to miners. However this leaves a parameter that affects every
> Bitcoin participant in the control of a small minority. Of course we can
> not
> force miners to increase the blocksize if they choose to decrease it,
> because
> the contents of the blocks they make are their decision and their decision
> only. However proposals to leave the maximum size unlimited to allow
> miners to
> force us to accept arbitrarily large blocks even if the will of the
> majority of
> Bitcoin participants is that they wish to remain able to validate the
> blockchain.
>
> What we need is a way to balance this asymetrical power relationship.
>
> Proof-of-stake voting gives us a way of achieving that balance.
> Essentially for
> a miner to prove that the majority will of the poeple is to accept a larger
> blocksize they must prove that the majority has in fact voted for that
> increase. The upper limit on the blocksize is then determined by the
> median of
> all votes, where each txout in the UTXO set is one vote, weighted by txout
> value. A txout without a corresponding vote is considered to be a vote for
> the
> status quo. To allow the voting process to continue even if coins are
> "lost"
> votes, including default votes, are weighted inversely according to their
> age
> in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old
> will be
> recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day
> old
> and 6 months old UTXO are treated equivalently. The 1 year minimum is
> simply to
> make voting required no more than once per year. (of course, a real
> implementation should do all of these figures by block height, IE after
> 52,560
> blocks instead of after 1 year)
>
> A vote will consist of a txout with a scriptPubKey of the following form:
>
> OP_RETURN magic vote_id txid vout vote scriptSig
>
> Where scriptSig is a valid signature for a transaction with nLockTime
> 500,000,000-1 spending txid:vout to scriptPubKey:
>
> OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> vote_id is the ID of the specific vote being made, and magic is included to
> allow UTXO proof implementations a as yet unspecified way of identifying
> votes
> and including the weighted median as part of the UTXO tree sums. (it also
> allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
> scriptPubKeys) vote is just the numerical vote itself. The vote must
> compute
> the median, rather than the mean, so as to not allow someone to skew the
> vote
> by simply setting their value extremely high. Someone who still remembers
> their
> statistics classes should chime in on the right way to compute a median in
> a
> merkle-sum-tree.
>
> The slightly unusual construction of votes makes implementation by wallet
> software as simple as possible within existing code-paths. Votes could
> still be
> constructed even in wallets lacking specific voting capability provided the
> wallet software does have the ability to set nLockTime.
>
> Of course in the future the voting mechanism can be used for additional
> votes
> with an additional vote_id. For instance the Bitcoin community could vote
> to
> increase the inflation subsidy, another example of a situation where the
> wishes
> of miners may conflict with the wishes of the broader community.
>
> Users may of course actually create these specially encoded txouts
> themselves
> and get them into the blockchain. However doing so is not needed as a
> given
> vote is only required to actually be in the chain by a miner wishing to
> increase the blocksize. Thus we should extend the P2P protocol with a
> mechanism
> by which votes can be broadcast independently of transactions. To prevent
> DoS
> attacks only votes with known vote_id's will be accepted, and only for
> txid:vout's already in the blockchain, and a record of txouts for whom
> votes
> have already broadcast will be kept. (this record need not be
> authoritative as
> its purpose is only to prevent DoS attacks) Miners wishing to increase the
> blocksize can record these votes and include them in the blocks they mine
> as
> required. To reduce the cost of including votes in blocks 5% of every block
> should be assigned to voting only. (this can be implemented by a soft-fork)
>
> For any given block actual limit in effect is then the rolling median of
> the
> blocks in the last year. At the beginning of every year the value
> considered to
> be the status quo resets to the mean of the limit at the beginning and end
> of
> the interval. (again, by "year" we really mean 52,560 blocks) The rolling
> median and periodic reset process ensures that the limit changes gradually
> and
> is not influenced by temporary events such as hacks to large exchanges or
> malicious wallet software. The rolling median also ensures that for a
> miner
> the act of including a vote is never wasted due to the txout later being
> spent.
>
> Implementing the voting system can happen prior to an actual hard-fork
> allowing
> for an increase and can be an important part of determining if the
> hard-fork is
> required at all.
>
> Coercion and vote buying is of course possible in this system. A miner
> could
> say that they will only accept transactions accompanied by a vote for a
> given
> limit. However in a decentralized system completely preventing vote buying
> is
> of course impossble, and the design of Bitcoin itself has a fundemental
> assumption that a majority of miners will behave in a specific kind of
> "honest"
> way.
>
> A voting process ensures that any increase to the blocksize genuinely
> represents the desires of the Bitcoin community, and the process described
> above ensures that any changes happen at a rate that gives all participants
> time to react. The process also gives a mechanism for the community to
> vote to
> decrease the limit if it turns out that the new one was in fact too high.
> (note
> how the way the status quo is set ensures the default action is for the
> limit
> to gradually decrease even if everyone stops voting)
>
> As many of you know I have been quite vocal that the 1MB limit should
> stay. But
> I would be happy to support the outcome of a vote done properly, whatever
> that
> outcome may be.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH
> Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H
> gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS
> ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj
> gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6
> Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=
> =aKBD
> -----END PGP SIGNATURE-----
>
-1
Firstly I appreciate the ingenious thought that went into this post.
However, Bitcoin's fundamental philosophy was one CPU one vote.
Voting is easily gamed. While this may work in one particular case, it is
perhaps a bad precedent to set. Establishing methods of voting can lead to
single points of failure.
The asymmetry lies in psychological terms, in that new defaults tend to be
adopted 80% of the time, so core devs have disproportionate amount of power
as things stand.
Unless there's a very good reason not to, e.g. miners are clearly abusing
the system, we should stick with 1 CPU one vote.
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130610/e22f5db1/attachment.html>

2023-06-07 15:02:57 UTC

- reply

📅 Original date posted:2013-06-06
📝 Original message:There was a discussion on #bitcon-dev yesterday
I stated that it would be impractical to generate two bitcoin addresses,
such that they differed in exactly one character (modulo different
checksums).
The corollary to this is that if you find an address with a verifiable
signature. Changing one character of that address would have no known
private key, and hence be normally undependable.
Does that sound correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/4bd0ab7f/attachment.html>

2023-06-07 15:02:43 UTC

- reply

📅 Original date posted:2013-06-06
📝 Original message:On 6 June 2013 21:59, Andreas M. Antonopoulos <andreas at rooteleven.com>wrote:
> Is there any consideration given to the fact that bitcoin can operate as a
> platform for many other services, if it is able to be neutral to payload,
> as long as the fee is paid for the transaction size?
>
> Unless I have misunderstood this discussion, it seems to me that this is a
> bit like saying in 1990 "IP Is only for email, the majority of users want
> email, we shouldn't allow video, voice or images". Ooops, there goes the
> web.
>
> Is it possible to solve this by solving the issue of provably un-spendable
> outputs without foreclosing on the possibility of other types of
> transaction payloads (ie, not money), that would open the possibility for a
> myriad of layered apps above? For example, hashes of content that is
> external to bitcoin, that people want to pay to have timestamped in the
> blockchain, as provably unspendable outputs.
>
> The social compact is to accept transaction for fee. I think it is a major
> mistake to make decisions that discriminate on the content of the
> transaction, saying that some uses are not appropriate. If the fee is paid
> and it covers the size of the transaction, why would it matter if it is not
> a payment?
>
> I could be totally misreading this thread, too, so please allow me some
> slack if I have!
>
+1 we're still early into the bitcoin story ... unexpected reuse should not
be ruled out ...
>
>
>
>
> On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke at dashjr.org> wrote:
>
>> On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
>> > scriptPubKey: <data> OP_TRUE
>> >
>> > ...
>> > Along with that change anyone-can-spend outputs should be make
>> IsStandard()
>> > so they will be relayed.
>>
>> Data does not belong in the blockchain. People running nodes have all
>> implicitly agreed to store the blocks for financial purposes, and storing
>> data
>> is a violation of that social contract. Proof-of-stake may be arguably
>> financial, but I'm sure there must be a way to do it without spamming
>> people
>> against their consent.
>>
>> > The alternative is sacrifices to unspendable outputs, which is very
>> > undesirable compared to sending the money to miners to further
>> > strengthen the security of the network.
>>
>> The alternative is to make other standard outputs unable to store data as
>> well.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> How ServiceNow helps IT people transform IT departments:
>> 1. A cloud service to automate IT design, transition and operations
>> 2. Dashboards that offer high-level views of enterprise services
>> 3. A single system of record for all IT processes
>> http://p.sf.net/sfu/servicenow-d2d-j
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/befb429c/attachment.html>

2023-06-07 15:02:39 UTC

- reply

📅 Original date posted:2013-06-03
📝 Original message:On 1 June 2013 21:30, Peter Todd <pete at petertodd.org> wrote:
> Currently the most compact way (proof-size) to sacrifice Bitcoins that
> does not involve making them unspendable is to create a anyone-can-spend
> output as the last txout in the coinbase of a block:
>
> scriptPubKey: <data> OP_TRUE
>
> The proof is then the SHA256 midstate, the txout, and the merkle path to
> the block header. However this mechanism needs miner support, and it is
> not possible to pay for such a sacrifice securely, or create an
> assurance contract to create one.
>
Sorry if this is a stupid question, but why would someone want to sacrifice
their bitcoins?
>
> A anyone-can-spend in a regular txout is another option, but there is no
> way to prevent a miner from including a transaction spending that txout
> in the same block. Once that happens, there is no way to prove the miner
> didn't create both, thus invalidating the sacrifice. The announce-commit
> protocol solves that problem, but at the cost of a much larger proof,
> especially if multiple parties want to get together to pay the cost of
> the sacrifice. (the proof must include the entire tx used to make the
> sacrifice)
>
> However if we add a rule where txouts ending in OP_TRUE are unspendable
> for 100 blocks, similar to coinbases, we fix these problems. The rule
> can be done as a soft-fork with 95% support in the same way the
> blockheight rule was implemented. Along with that change
> anyone-can-spend outputs should be make IsStandard() so they will be
> relayed.
>
> The alternative is sacrifices to unspendable outputs, which is very
> undesirable compared to sending the money to miners to further
> strengthen the security of the network.
>
> We should always make it easy for people to write code that does what is
> best for Bitcoin.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130604/0230ef96/attachment.html>

2023-06-07 15:02:26 UTC

- reply

📅 Original date posted:2013-05-25
📝 Original message:On 25 May 2013 07:46, Zooko Wilcox-OHearn <zooko at leastauthority.com> wrote:
> jgarzik wrote:
> > 1) Rule changes. We don't want these.
>
> In general? What constitutes a rule change?
>
> For example, if I understand correctly (from what Gavin said at
> Bitcoin 2013), there is a move afoot to lift the block size limit.
> Although, when I went to confirm my understanding by reading the
> bitcoin-development list archives, I don't see mention of this. Is
> there another forum I should be reading if I want to follow Bitcoin
> development?
>
> Anyway, I hope that there are some rule changes that you would
> consider for Bitcoin, although I recognize there are vast classes of
> such changes that you wouldn't.
>
> I'm trying to figure out what's the most productive way to show you,
> and everyone, candidates for such changes. Things that are definitely
> not suitable for merging to trunk tomorrow, but might be suitable in a
> year or two, or "Next Time We Have A Hardfork".
>
> I don't think alternative bitcoin-clones are the best venue for those.
> Although they are certainly good venues for changes which can never
> make it into Bitcoin.
>
> Perhaps the best venue for such a thing is just to fork bitcoin.git on
> github.
>
It might be an idea to have 'rule change' fixes and 'bug fix' releases go
out separately
>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.com
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130525/84a6f9ae/attachment.html>

2023-06-07 14:56:38 UTC

- reply

📅 Original date posted:2013-05-07
📝 Original message:Looking at the proposed native crypto browser support (should arrive in the
next year)
http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary
We see:
enum NamedCurve {
// NIST recommended curve P-256, also known as secp256r1.
"P-256",
// NIST recommended curve P-384, also known as secp384r1.
"P-384",
// NIST recommended curve P-521, also known as secp521r1.
"P-521"
};
I wonder if we might be able to get bitcoin's curve in there
For more background on Koblitz curve used by bitcoin see:
https://bitcointalk.org/?topic=2699.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130507/0f3dc6b8/attachment.html>

2023-06-07 14:56:38 UTC

- reply

📅 Original date posted:2013-05-29
📝 Original message:On 7 May 2013 12:18, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> Looking at the proposed native crypto browser support (should arrive in
> the next year)
>
> http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary
>
> We see:
>
> enum NamedCurve {
> // NIST recommended curve P-256, also known as secp256r1.
> "P-256",
> // NIST recommended curve P-384, also known as secp384r1.
> "P-384",
> // NIST recommended curve P-521, also known as secp521r1.
> "P-521"
> };
>
> I wonder if we might be able to get bitcoin's curve in there
>
> For more background on Koblitz curve used by bitcoin see:
>
> https://bitcointalk.org/?topic=2699.0
>
Hi All
I enuired about this and got the following reply, from the chair of the
crypto group:
[[
Just email public-webcrypto-comments at w3.org. It's a public list. Do
definitely mention your use-cases!
I think there's issues of whether NSS etc. already support it. I think the
answer here is "no" but David can clarify. The goal is not to get browser
vendors to write new crypto code, but to expose the crypto code that
already exists.
We still have an open issue about whether "experimental" registry for
identifiers for say, new curves that aren't in the core spec, will be
maintained. So, maybe if browsers don't support it today, it's always
possible they might want to support it tomorrow given Bitcoin's growth.
]]
Please let me know if anyone has a use case for ecdsa in the browser let me
know.
Or if anyone would like to write to the public list that's fine
Otherwise I'll just fire off a mail and see what they come back with ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130529/f396cd94/attachment.html>

2023-06-07 11:43:22 UTC

- reply

📅 Original date posted:2013-04-05
📝 Original message:There was some chat on IRC about a mining pool reaching 46%
http://blockchain.info/pools
What's the risk of a 51% attack.
I suggested that the pool itself is decentralized so you could not launch
one
On IRC people were saying that the pool owner gets to choose what goes in
the block
Surely with random non colliding nonces, it would be almost impossible to
coordinate a 51% even by the owner
Someone came back and said that creating random numbers on a GPU is hard.
But what about just creating ONE random number and incrementing from there
...
It would be great to know if this is a threat or a non issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130405/50bc41ef/attachment.html>

2023-06-07 11:42:43 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:On 2 April 2013 00:10, Will <will at phase.net> wrote:
> The threat of a SHA1 collision attack to insert a malicious pull request
> are tiny compared with the other threats - e.g. github being compromised,
> one of the core developers' passwords being compromised, one of the core
> developers going rogue, sourceforge (distribution site) being compromised
> etc etc... believe me there's a lot more to worry about than a SHA1
> attack...
>
> Not meaning to scare, just to put things in perspective - this is why we
> all need to peer review each others commits and keep an eye out for
> suspicious commits, leverage the benefits of this project being open source
> and easily peer reviewed.
>
Very good points, and I think you're absolutely right.
But just running the numbers, to get the picture, based of scheiner's
statistics:
http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
We're talking about a million terrahashes = 2^60 right?
With the block chain, you only have a 10 minute window, but with source
code you have a longer time to prepare.
Couldnt this be done with an ASIC in about a week?
>
> Will
>
>
> On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>
>>
>>
>>
>> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
>>
>>> An attacker would have to find a collision between two specific pieces
>>> of code - his malicious code and a useful innoculous code that would be
>>> accepted as pull request. This is the second, much harder case in the
>>> birthday problem. When people talk about SHA-1 being broken they actually
>>> mean the first case in the birthday problem - find any two arbitrary values
>>> that hash to the same value. So, no I don't think it's a feasible attack
>>> vector any time soon.
>>>
>>> Besides, with that kind of hashing power, it might be more feasible to
>>> cause problems in the chain by e.g. constantly splitting it.
>>>
>>
>> OK, maybe im being *way* too paranoid here ... but what if someone had
>> access to github, could they replace one file with one they had prepared at
>> some point?
>>
>>
>>>
>>>
>>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>>>
>>>> I was just looking at:
>>>>
>>>> https://bitcointalk.org/index.php?topic=4571.0
>>>>
>>>> I'm just curious if there is a possible attack vector here based on the
>>>> fact that git uses the relatively week SHA1
>>>>
>>>> Could a seemingly innocuous pull request generate another file with a
>>>> backdoor/nonce combination that slips under the radar?
>>>>
>>>> Apologies if this has come up before ...
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Own the Future-Intel® Level Up Game Demo Contest 2013
>>>> Rise to greatness in Intel's independent game demo contest.
>>>> Compete for recognition, cash, and the chance to get your game
>>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
>>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Own the Future-Intel® Level Up Game Demo Contest 2013
>> Rise to greatness in Intel's independent game demo contest.
>> Compete for recognition, cash, and the chance to get your game
>> on Steam. $5K grand prize plus 10 genre and skill prizes.
>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130402/7b3c7f99/attachment.html>

2023-06-07 11:42:37 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
> An attacker would have to find a collision between two specific pieces of
> code - his malicious code and a useful innoculous code that would be
> accepted as pull request. This is the second, much harder case in the
> birthday problem. When people talk about SHA-1 being broken they actually
> mean the first case in the birthday problem - find any two arbitrary values
> that hash to the same value. So, no I don't think it's a feasible attack
> vector any time soon.
>
> Besides, with that kind of hashing power, it might be more feasible to
> cause problems in the chain by e.g. constantly splitting it.
>
OK, maybe im being *way* too paranoid here ... but what if someone had
access to github, could they replace one file with one they had prepared at
some point?
>
>
> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>
>> I was just looking at:
>>
>> https://bitcointalk.org/index.php?topic=4571.0
>>
>> I'm just curious if there is a possible attack vector here based on the
>> fact that git uses the relatively week SHA1
>>
>> Could a seemingly innocuous pull request generate another file with a
>> backdoor/nonce combination that slips under the radar?
>>
>> Apologies if this has come up before ...
>>
>>
>> ------------------------------------------------------------------------------
>> Own the Future-Intel® Level Up Game Demo Contest 2013
>> Rise to greatness in Intel's independent game demo contest.
>> Compete for recognition, cash, and the chance to get your game
>> on Steam. $5K grand prize plus 10 genre and skill prizes.
>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130401/073ada84/attachment.html>

2023-06-07 11:42:30 UTC

- reply

📅 Original date posted:2013-04-01
📝 Original message:I was just looking at:
https://bitcointalk.org/index.php?topic=4571.0
I'm just curious if there is a possible attack vector here based on the
fact that git uses the relatively week SHA1
Could a seemingly innocuous pull request generate another file with a
backdoor/nonce combination that slips under the radar?
Apologies if this has come up before ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130401/ee3f75c4/attachment.html>