Melvin Carvalho [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-12-16 to 2023-05-08
💬 Posted a total of 105 messages
📚 Participated in the following categories: Bitcoin-development, RFC, ann, Bug 24444, ANN, bitcoin-dev, Mempool spam, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrt

Profile Code

nprofile1qqswx95kvv5vfjmxcdr3nmu60vau2nhkq9nr449tqcv9nyfrwu665xgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqgcwaehxw309aex2mrp0yhxummnwa5x2un99e3k7mgnks4tk

Publishing to

relay.nostr.band

relay.noswhere.com

Author Public Key

npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrt

Show more details

Last Notes

2023-06-09 12:54:05

- 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

- 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

- 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

- 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

- 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

- 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 23:21:31

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Bitcoin mempool is congested due to high volume of BRC-20 tokens, causing real transactions to be priced out. Discussions on potential solutions and actions to prevent future congestion.
📝 Original message:po 8. 5. 2023 v 13:55 odesílatel Ali Sherief via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> napsal:
> Hi guys,
>
> I think everyone on this list knows what has happened to the Bitcoin
> mempool during the past 96 hours. Due to side projects such as BRC-20
> having such a high volume, real bitcoin transactions are being priced out
> and that is what is causing the massive congestion that has arguable not
> been seen since December 2017. I do not count the March 2021 congestion
> because that was only with 1-5sat/vbyte.
>
> Such justifiably worthless ("worthless" is not even my word - that's how
> its creator described them[1]) tokens threaten the smooth and normal use of
> the Bitcoin network as a peer-to-pear digital currency, as it was intended
> to be used as.
>
> If the volume does not die down over the next few weeks, should we take an
> action? The bitcoin network is a triumvirate of developers, miners, and
> users. Considering that miners are largely the entities at fault for
> allowing the system to be abused like this, the harmony of Bitcoin
> transactions is being disrupted right now. Although this community has a
> strong history of not putting its fingers into pies unless absolutely
> necessary - an example being during the block size wars and Segwit - should
> similar action be taken now, in the form of i) BIPs and/or ii) commits into
> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which
> defines the validation rules for Taproot scripts) which has allowed these
> unintended consequences?
>
> An alternative would be to enforce this "censorship" at the node level and
> introduce a run-time option to instantly prune all non-standard Taproot
> transactions. This will be easier to implement, but won't hit the road
> until minimum next release.
>
> I know that some people will have their criticisms about this,
> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
> need to find a solution for this that fits everyone's common ground. We
> indirectly allowed this to happen, which previously wasn't possible before.
> So we also have a responsibility to do something to ensure that this kind
> of congestion can never happen again using Taproot.
>
This is a nuanced and sensitive topic that has been discussed previously,
as far back as 2010, in a conversation between Gavin and Satoshi:
https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
Gavin: That's a cool feature until it gets popular and somebody decides it
would be fun to flood the payment network with millions of transactions to
transfer the latest Lady Gaga video to all their friends...
Satoshi: That's one of the reasons for transaction fees. There are other
things we can do if necessary.
High fees could be viewed as disruptive to the network, but less disruptive
than regular large reorgs, or a network split.
It might be beneficial to brainstorm the "other things we can do if
necessary".
A simple observation is that increasing the block size could make it more
challenging to spam, though it may come at the expense of some
decentralization.
> -Ali
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
> _______________________________________________
> 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/20230508/2b4d1b46/attachment-0001.html>

2023-06-07 23:19:20

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: A Bitcoin developer questions the wisdom of allowing unlimited storage of NFT content on the blockchain and suggests imposing a size limit. A low-tech solution proposed is to charge a premium for storing images in the blockchain.
📝 Original message:pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> napsal:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
>
Low tech solution: miners charge a premium for storing images in the block
chain. Say 2x, 5x, 10x.
This encourages bitcoin to be used as a financial network, while increasing
the security budget.
>
> _______________________________________________
> 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/20230203/ecd518a8/attachment.html>

2023-06-07 23:08:15

- reply

📅 Original date posted:2022-04-26
📝 Original message:On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the next few weeks go how I fear they will it could get messy. If you
> care about Bitcoin's consensus rules I'd request you pay attention so you
> can make an informed view on what to run and what to support. For those of
> you who were around in 2015-2017 you'll know what to expect. The right
> outcome endured in 2017 and I'm sure the right outcome will endure here
> assuming people pay attention and listen to the individuals who were
> trusted during that period. There are always a large number of motivated
> parties who are incentivized to break nodes off from Bitcoin and may seek
> to take advantage of a contentious soft fork activation attempt.
>
> Remember that if all the information is presented to users in a clear way
> well ahead of time then they can make their own mind up. I fear that things
> will be made as convoluted as possible in a way intended to confuse and
> information will be withheld until the last minute. When in doubt it is
> generally better to rely on the status quo and tried and trusted. In this
> case that would be Bitcoin Core. Alternative releases such as those seeking
> to attempt to activate CTV or indeed those seeking to resist the activation
> of CTV really should only be considered if you are informed on exactly what
> you are running.
>
> If you are interested in the effort to resist the contentious soft fork
> activation attempt of CTV please join ##ursf on Libera IRC.
>
> Have a good weekend. Hopefully those behind this contentious soft fork
> activation attempt will see sense and we can go back to more productive
> things than resisting contentious soft forks.
>
Thanks for raising this
Remembering 2017 quite well, it's often characterized as small block(ers)
vs big block(ers). While that was certainly the case, I see it slightly
differently.
I think the bigger argument of 2017 was around a network split. Splitting
the network is problematic because one or other of the split chains may
experience a hash death (without mitigating difficulty adjustment
algorithms), or the so-called "famine and feast" minority hash behaviour,
experienced on testnet, and disruptive to users
Any proposed changes should factor in network splits as a potential risk.
Or perhaps through another lens, you could see a network split as an
attack, on a par with a 51% attack, in terms of user disruption. It may in
fact, be more potent, since we've never had a serious 51% attack, but we
have had network splits
I do think the conversation here is MUCH better tempered than 2017.
Hopefully we can try and avoid perceptions of gate keeping and railroading,
and keep the network together, as we did back then
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> 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/20220426/1c0c7197/attachment-0001.html>

2023-06-07 22:54:02

- reply

📅 Original date posted:2021-05-25
📝 Original message:On Mon, 24 May 2021 at 22:32, Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Before we can decide on tradeoffs that reduce security in favor of less
> energy usage, or less inflation, or whatever goal you might have for
> reducing (or delaying) coinbase rewards, we need to decide as a community
> how much security bitcoin *needs*.
>
> Do we need to be secure against an attacker with a budget of $1
> billion/year for an attack? $10 billion/year? More?
>
> An upper limit would be the budget of the largest government: the US. The
> US federal budget is almost $5 trillion/year. But they certainly couldn't
> spend all that budget attacking bitcoin. About $3 trillion of that is
> mandatory spending, which couldn't be allocated to such an attack. About
> $1.5 trillion is discretionary, which includes the military budget. It
> seems like an upper limit on the amount that could be siphoned from that
> budget to attack bitcoin would be 5%. That would take massive political
> cooperation and wheeling and dealing. Likely spending that much would not
> be politically feasible, but it seems possible, since a 5% reduction in
> other activities is something other departments would likely be able to
> sustain with just a bit of downsizing. Or that money could simply come from
> more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
> pretty solid upper limit on the amount the US could allocate to an attack
> in a year, in that it seems incredibly unlikely that more money than that
> could be allocated. Such an expenditure might be eventually seen as
> justified since the federal reserve has been inflating the supply of
> dollars by 17.5% on average every year, which would be $1 trillion next
> year (and more the next, etc). A similar story is told if you calculate the
> amount of seigniorage banks get access to by their ability to use
> fractional reserve to inflate the supply of M2 money. It should be
> considered tho that this seigniorage doesn't give its beneficiaries that
> full value, but rather some fraction of that value - say 5% earned by being
> first to buy with that new money and earning interest on it. So 5% of a
> trillion is $50 billion. Still, over just two years, that's enough to pay
> for an attack of at least that size ($75 billion).
>
> The budget for the government of China is about $3.6 trillion, the second
> largest in the world. And since they're an authoritarian country, they can
> basically do whatever they want with that money. It still seems unlikely
> they would spend more than 5% of that budget on doing something like
> attacking bitcoin. However, consider that China's M2 money supply has been
> increasing at a rate of almost $3 trillion per year. Protecting the ability
> to do this is seems like something worth spending some (printed) money on.
> So perhaps at some point, spending 10 or 20% of their budget for a year or
> two to attack bitcoin might seem like a good idea to some mickey mouse in
> the government. That would be $720 billion/year.
>
> So given the amount of seigniorage taken in every year by these central
> banks, it would seem to justify large expenditures. I'm not sure how
> realistic it would be, politically speaking, to gather $720 billion in a
> single year to attack bitcoin. It seems far fetched, even if the
> seigniorage they're protecting seems to justify it.
>
> So is this the level of attack we want to be resilient to? Nearly a $1
> trillion attack? I don't know. But we should figure that out as a
> community. And keep in mind, the level of attack we need to defend against
> depends on the size of bitcoin. The more valuable bitcoins are, the more
> damaging, more lucrative, and more valuable an attack would be for
> attackers. Its seems reasonable to assume that this is a linear
> relationship - that if bitcoins are worth twice as much, we need twice as
> much security (ie we want to make attacking bitcoin twice as costly).
>
> The next step is figuring out a reasonable lower bound for how much it
> takes to attack bitcoin. There are many attacks that can be done on
> bitcoin, but the one relevant to the discussion here is a 51% attack.
> Bitcoin's PoW basically is attackable buy buying about 25% of the existing
> mining power (for reasons like the selfish economic attack
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack> and
> the economic mining monopoly attack
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#economic-mining-monopoly-attack>),
> which is about 40 exahashes/second.
>
Agree that it is valuable to find a reasonable lower bound to how much it
take to 'attack' bitcoin
Two observations:
1. The security model of bitcoin is dual and heterogeneous. There is both
a block subsidy and a fee model. These are not like for like. One is
steady, and one fluctuates. You might make the analogy with steady nuclear
power, and intermittent wind power. That means that an attack is more
effective when fees are at their lowest. We observe that fees tend to
build up during the week and are cleared during the weekend, right now.
Less of an issue right now, but in 3, 7, 11 years fees will make up a
larger proportion of the total block reward, so maybe something to factor in
2. From the point of view of bitcoin an 'attack' is simply making the chain
stronger (or longer) by increasing the accumulated proof of work. From the
point of view of applications that rely on bitcoin blocks (layer2,
exchanges, markets etc.) a reorg could be seen as disruptive, requiring
more confirmations for larger transactions. We might want to take a view
on what a planned 'attack' or regorg might look like. Satoshi when he put
the first checkpoint in used 200 blocks as a guide. Straw polling the
community on this question has lead me to believe that there is a wide
range of views on how large a reorg would constitute an attack
IMHO it's valuable to work out what the community feels an attack might
look like, and a lower bound to the cost. over time. Bearing in mind
there's going to be a wide spectrum of opinion, on the topic
But, given that there's not been a successful attack in the last decade, we
probably have a decent amount of time to figure this out
>
> If you bought 400,000 WhatsMiner M30S+ rigs
> <https://www.buybitcoinworldwide.com/mining/hardware/> at current market
> price, you'd need $1 billion to buy them all (which doesn't include the
> cost of setting up all that equipment, powering it, building the network
> infrastructure for it, etc etc). Let's say all that infra doubles the price
> to $2 billion. Even then, you couldn't simply buy half a million mining
> rigs from the market. That many just aren't available. An attacker would
> have to spend year and years building up their mining operation before they
> could actually perform the attack. They'd basically have to mine at a
> slight (probably insignificant) loss for that time. Their demand would push
> up the price of these mining rigs for at least a year or two until supply
> comes up to meet it. So lets say this doubles the price of the mining rigs
> (it could very well do significantly more than that). That makes for $3
> billion to build up this malicious mining operation. China could seize a
> mining pool, but likely couldn't do it quietly. They'd have to seize the
> pool and immediately use it to attack before miners stop using the pool
> (which might take a week or two). Maybe this would save them half the cost?
>
> So, lower bound on cost of attack is $1.5 billion. Upper bound on US govt
> attack is $72 billion. Upper bound on China govt attack is $720 billion. So
> based on this back-of-the-napkin line of thinking, its not super clear that
> reducing bitcoin's security is "enough" yet. There is also the question of:
> does a $1 trillion currency need to be secure against a $720 billion
> attack? Probably not. But should it be secure against a $10 billion attack?
> Maybe.
>
> However, the security will go up with price. If bitcoin goes up by 10x, as
> it is wont to do, that's nearly 10x the security (nearly, since coinbase
> rewards 10x, but the real value of fees almost certainly wouldn't go up as
> much). So that brings us to $15 billion of security. Still not clear
> without doing some more accurate analysis to determine more confidence in
> tighter bounds on cost of attack and likely attack budgets.
>
> But it certainly seems likely that my attack cost bounds are an order of
> magnitude too low, and its equally possible my estimates of potential
> available attack budgets are an order of magnitude too high. It doesn't
> seem quite as likely the reverse is true (that my bounds aren't good
> bounds).
>
> It seems possible that we currently have enough security, but seems
> likelier that we don't. It just isn't clear to me. Maybe someone has done
> some more accurate analysis that could help here.
>
> But before we talk about whether we should reduce our security to save
> costs, we need to determine how much security we need and how much security
> we have. Without good estimates with confident bounds, we simply can't make
> an informed decision to reduce security.
>
> > I don't think 99% of transactions need that level of security
>
> Well you can't get security for the 1% of transactions that need it
> without giving that security to all transactions on the chain. Also, the
> blockchain security created by miners isn't really a per transaction thing
> anyway. An attack would affect all bitcoins regardless of what transactions
> they do or do not take part in.
>
> On Sun, May 23, 2021 at 9:52 AM Karl via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> >> The turn-around time for that takes a population of both users and
>> >> miners to cause. Increasing popularity of bitcoin has a far bigger
>> >> impact here, and it is already raising fees and energy use at an
>> >> established rate.
>> >>
>> >> If it becomes an issue, as bandwidth increases block size could be
>> >> raised to lower fees.
>> >>
>> >
>> > Which increases block rewards somewhat (at least to some level that
>> matches
>> > the overall security of the network) and you still have the same amount
>> of
>> > energy consumed.
>>
>> If you mean to implicitly propose that even if halved all the way with
>> very large blocks, block rewards would just increase to the same
>> level, meaning that any attempt to decrease them has no effect, I
>> disagree. I expect that if you raise the block size, eventually
>> there is so much supply for transactions that there are no fees at all
>> (nor security). The numbers are all things the devs, miners, and
>> users can together control.
>>
>> > How to prove this is not happening?
>> > The best you can do is to have some number of authorities sign off on
>> > whether or not they are doing this.
>> > The problem is that authorities are bribeable.
>>
>> You could make the proof of work be a proof of environmental kindness
>> by coding incentives for people to place and verify proof on the
>> chain, and then rewarding people for acting on it as desired. You
>> could code the chain to pay people to investigate and prove miners'
>> business practices, for example. You could define the main chain as
>> one where everyone consents the proofs are valid. There are a lot of
>> issues to resolve and it would be a very different chain.
>>
>> There is not a single solution here. There are innumerable possible
>> solutions, any one of which could be made to work with enough brains
>> working on it. To use one, we need to agree on what kinds of
>> solutions are acceptable.
>>
>> > Alternately, other entities in the locality can use force to require the
>> > polluting entity to clean up or suffer significant consequences.
>> > This at least is better incentive-wise, as they others in the same
>> locality
>> > are the ones most affected, but the ability to enforce may be difficult
>> due
>> > to various political constructions; the miners could be in such deep
>> cahoots
>> > with the local government that the local government would willingly hurt
>> > other local entities in the vicinity of the polluting entity.
>>
>> As bitcoin grows, if people ask some locality to enforce behavior,
>> they may need to be willing to enforce it themselves, too, or they
>> might outcompete the locality.
>> _______________________________________________
>> 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/20210525/51ca7794/attachment-0001.html>

2023-06-07 22:52:11

- 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 18:30:03

- reply

📅 Original date posted:2021-03-04
📝 Original message:On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Consensus is important for both taproot and separately for the activation
> mechanism. There are more soft-forks that Bitcoin will need, so it is
> important to achieve positive progress on the activation topic also, not
> get impatient and rush something ill-considered. Not all future soft-forks
> maybe as widely supported as taproot, and yet it could become existentially
> critical that Bitcoin prevails in achieving a future upgrade in dramatic
> circumstances, even against powerful interests counter to Bitcoin user and
> investors interests. We should treat the activation topic in a considered
> way and with decorum, provide tight non-emotive reasoning devoid of
> frustration and impatience. This is a low drama and convenient time to
> incrementally improve activation. People have varied views about the
> deciding factor, or even which factors resulted in segwit activating after
> BIP 141 failed using BIP 9. We do not have to solve everything in one
> step, incremental improvement is good, for complex unintuitive topics, to
> learn as we go - and it should not be hard to do less badly than what
> transpired leading up to BIP 148 and BIP 91. Failure to upgrade if
> permanent, or demoralizing to protocol researchers could be a systemic risk
> in itself as there are more upgrades Bitcoin will need. We are not Ents
> but we should use our collective ingenuity to find an incremental
> improvement for activation.
>
Great high level thoughts
The Ents themselves were created in Tolkien's fork of Shakespeare, when he
was frustrated to learn that trees didnt actually march :)
Having followed standards for 10+ years consensus can be tricky
IIRC last time with segwit there was a straw poll in the wiki where devs
could express leanings in an informal, async way. Something like that
could be of value.
There's an insightful spec written at the IETF "On Consensus and Humming in
the IETF", then IMHO is worth reading
https://tools.ietf.org/html/rfc7282
That said, if we could find an incorruptible machine that could gather the
highest fee tx from the mempool and post it every 10 minutes, bitcoin would
largely run itself. So, while understanding the gravity of each change, we
could perhaps have the mindset that there are a finite number, such that
when complete bitcoin will move to an endgame where for the user it 'just
works', much like the internet. If devs and changes are needed less, that
could be viewed as a sign of success. This is a hand wavy way of saying
that forks could potentially be a diminishing issue over time
Just my 2 satoshis
>
> John R
> _______________________________________________
> 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/20210304/54504948/attachment-0001.html>

2023-06-07 18:17:18

- reply

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

2023-06-07 18:10:44

- reply

📅 Original date posted:2018-02-12
📝 Original message:On 21 December 2017 at 22:30, Melvin Carvalho <melvincarvalho at gmail.com>
wrote:
> I asked adam back at hcpp how the block chain would be secured in the long
> term, once the reward goes away. The base idea has always been that fees
> would replace the block reward.
>
> At that time fees were approximately 10% of the block reward, but have now
> reached 45%, with 50% potentially being crossed soon
>
> https://fork.lol/reward/feepct
>
> While this bodes well for the long term security of the coin, I think
> there is some legitimate concern that the fee per tx is prohibitive for
> some use cases, at this point in the adoption curve.
>
> Observations of segwit adoption show around 10% at this point
>
> http://segwit.party/charts/
>
> Watching the mempool shows that the congestion is at a peak, though it's
> quite possible this will come down over the long weekend. I wonder if this
> is of concern to some.
>
> https://dedi.jochen-hoenicke.de/queue/more/#24h
>
> I thought these data points may be of interest and are mainly FYI. Though
> if further discussion is deemed appropriate, it would be interesting to
> hear thoughts.
>
Just following up on this, for no other reason than I've had my eyes glued
to these stats the last few weeks. I'll share a few more stats links.
Mempool has come down significantly, as have fees. Tho, of course, this
could spike any time.
https://bitinfocharts.com/bitcoin/
Typically fees are :
$2.06 on tx $543 (median) # 0.38%
$3.47 on tx $75,000 (mean) # 0.005%
Aside: An observation on this. High value transactors seems to be getting
a much better deal, than the mean. This lead me to ponder whether the
intuitive metric of satoshi/byte is, in fact, game theory optimal.
Possibly over the short term it is, but over a longer period, those wishing
to increase the longevity of proof of work in general might wish to
consider more progressive fee approaches. Naively, it might be possible to
imagine some kind of gaussian distribution that picks tx according to a
blended combination of sats/byte and %transacted. Perhaps something for
miners and fee estimation algorithms to develop over time.
Segwit adoption has increased, and anecdotal evidence shows that trend to
continue. The release of 0.16 will I think also have a positive effect.
Finally, I came across this wonderful site that shows lightning network
adoption on mainnet
http://shabang.io/
LN is increasing well. Some blocks are not far off 1% lightning funding,
which I think bodes well. I'll go out on a limb and predict that over 1%
of btc tx will be lightning based by year end.
Since such posts are not strictly development, I'll keep them to a
minimum. However, I hope these stats provide useful data points for
project evolution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/e65cbca0/attachment.html>

2023-06-07 18:09:52

- reply

📅 Original date posted:2018-01-20
📝 Original message:On 17 January 2018 at 23:31, Jefferson Carpenter via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin's difficulty will be maxed out within about 400 years, by Moore's
> law. (After that - supposing the software does not crash when difficulty
> overflows - block time will start decreasing, and it will not take long
> before blocks are mined faster than photons can be sent across the planet).
>
> Bitcoin is the dominant cryptocurrency today, as the first mover: the
> perfectly fair worldwide game of inventing the cryptocurrency has been
> played and won. However, unfortunately, it has a built-in end date: about
> 400 years from now. After that, it won't necessarily be clear what the
> dominant cryptocurrency is. It might be a lot like VHS vs Betamax, and a
> lot of people could lose a lot of money. It seems to me, this could be
> mitigated by planning today for what we are going to do when Bitcoin
> finally breaks 400 years from now.
>
> Are there any distinct plans today for migrating to a PoW supporting an
> even higher difficulty?
>
Crypto algorithms have a lifetime, and consensus is no different.
Is it likely to be more than a few years? Yes.
Is likely to be less than a few hundred years. Yes.
Every algorithm involves trade offs and it's the job of a thoughtful dev
team to examine those trade offs and come to a consensus optimal solution.
This field is only 9 years old, and there is a large amount of R & D in
this area. So we can evaluate what seems to working better and what seems
to be working worse, transfer that to BIPs, create code, test it, try to
achieve consensus. The normal path that has served free software projects
well.
> _______________________________________________
> 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/20180120/5007b1f4/attachment.html>

2023-06-07 18:08:57

- reply

📅 Original date posted:2017-12-21
📝 Original message:I asked adam back at hcpp how the block chain would be secured in the long
term, once the reward goes away. The base idea has always been that fees
would replace the block reward.
At that time fees were approximately 10% of the block reward, but have now
reached 45%, with 50% potentially being crossed soon
https://fork.lol/reward/feepct
While this bodes well for the long term security of the coin, I think there
is some legitimate concern that the fee per tx is prohibitive for some use
cases, at this point in the adoption curve.
Observations of segwit adoption show around 10% at this point
http://segwit.party/charts/
Watching the mempool shows that the congestion is at a peak, though it's
quite possible this will come down over the long weekend. I wonder if this
is of concern to some.
https://dedi.jochen-hoenicke.de/queue/more/#24h
I thought these data points may be of interest and are mainly FYI. Though
if further discussion is deemed appropriate, it would be interesting to
hear thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/d2feec02/attachment.html>

2023-06-07 15:38:44

- reply

📅 Original date posted:2015-06-18
📝 Original message:On 18 June 2015 at 12:00, Mike Hearn <mike at plan99.net> wrote:
> Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
> already said long ago he wouldn't just commit something, even though he has
> the ability to do so.
>
> So why did I say it? Because it's consistent with what I've always said:
> you cannot run a codebase like Wikipedia. Maintainers have to take part in
> debates, and then make a decision, and anyone else who was delegated commit
> access for robustness or convenience must then respect that decision. It's
> the only way to keep a project making progress at a reasonable pace.
>
> This is not a radical position. That's how nearly all coding projects
> work. I have been involved with open source for 15 years and the 'single
> maintainer who makes decisions' model is normal, even if in some large
> codebases subsystems have delegated submaintainers.
>
> This is also how all my own projects are run. Bitcoinj has multiple people
> with commit access. Regardless, if there were to be some design dispute or
> whatever, I wouldn't tolerate the others with commit access starting some
> kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
> expect to get my own way in other people's projects by threatening to
> revert the maintainers changes.
>
> Core is in the weird position where there's no decision making ability at
> all, because anyone who shows up and shouts enough can generate
> 'controversy', then Wladimir sees there is disagreement and won't touch the
> issue in question. So it just runs and runs and *anyone* with commit
> access can then block any change.
>
> I realise some people think this anti-process leads to better decision
> making. I disagree. It leads to no decision making, which is not the same
> thing at all.
>
Bicoin is not like other projects. There are large financial stakes
involved. I was at a standards convention once and the head of standards
at a large company joked to me:
"We know there are 6 people in the standards world that we can never buy.
So we just buy everyone else".
You have to luck out in a huge way to get a person like that running your
project. Linux has done. Id say bitcoin has been lucky there too. But
have a look at other projects, have a look at the alts, the *last* thing
you want is a dictator in may cases.
Ultimately bitcoin is a ledger based on consensus. There are 3 branches,
the miners, the protocol and the market. They all play a role in
regulating bitcoin and generally on the conservative side (which I think is
a good thing). Whatever your view on the 20MB change, it's not a
*conservative* approach, which is the approach that has served bitcoin very
well so far.
So bitcoin is not like other open source projects, and that's probably
quite a good thing.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150618/80179ef4/attachment.html>

2023-06-07 15:34:48

- reply

📅 Original date posted:2015-05-13
📝 Original message:On 11 May 2015 at 18:28, Thomas Voegtlin <thomasv at electrum.org> wrote:
> The discussion on block size increase has brought some attention to the
> other elephant in the room: Long-term mining incentives.
>
> Bitcoin derives its current market value from the assumption that a
> stable, steady-state regime will be reached in the future, where miners
> have an incentive to keep mining to protect the network. Such a steady
> state regime does not exist today, because miners get most of their
> reward from the block subsidy, which will progressively be removed.
>
> Thus, today's 3 billion USD question is the following: Will a steady
> state regime be reached in the future? Can such a regime exist? What are
> the necessary conditions for its existence?
>
> Satoshi's paper suggests that this may be achieved through miner fees.
> Quite a few people seem to take this for granted, and are working to
> make it happen (developing cpfp and replace-by-fee). This explains part
> of the opposition to raising the block size limit; some people would
> like to see some fee pressure building up first, in order to get closer
> to a regime where miners are incentivised by transaction fees instead of
> block subsidy. Indeed, the emergence of a working fee market would be
> extremely reassuring for the long-term viability of bitcoin. So, the
> thinking goes, by raising the block size limit, we would be postponing a
> crucial reality check. We would be buying time, at the expenses of
> Bitcoin's decentralization.
>
> OTOH, proponents of a block size increase have a very good point: if the
> block size is not raised soon, Bitcoin is going to enter a new, unknown
> and potentially harmful regime. In the current regime, almost all
> transaction get confirmed quickly, and fee pressure does not exist. Mike
> Hearn suggested that, when blocks reach full capacity and users start to
> experience confirmation delays and confirmation uncertainty, users will
> simply go away and stop using Bitcoin. To me, that outcome sounds very
> plausible indeed. Thus, proponents of the block size increase are
> conservative; they are trying to preserve the current regime, which is
> known to work, instead of letting the network enter uncharted territory.
>
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain infrastructure first, such as the
> Lightning network.
>
> OTOH, I also fail to see evidence that a limited block capacity will
> lead to a functional fee market, able to sustain a steady state. A
> functional market requires well-informed participants who make rational
> choices and accept the outcomes of their choices. That is not the case
> today, and to believe that it will magically happen because blocks start
> to reach full capacity sounds a lot like like wishful thinking.
>
> So here is my question, to both proponents and opponents of a block size
> increase: What steady-state regime do you envision for Bitcoin, and what
> is is your plan to get there? More specifically, how will the
> steady-state regime look like? Will users experience fee pressure and
> delays, or will it look more like a scaled up version of what we enjoy
> today? Should fee pressure be increased jointly with subsidy decrease,
> or as soon as possible, or never? What incentives will exist for miners
> once the subsidy is gone? Will miners have an incentive to permanently
> fork off the last block and capture its fees? Do you expect Bitcoin to
> work because miners are altruistic/selfish/honest/caring?
>
> A clear vision would be welcome.
>
I am guided here by Satoshi's paper:
"Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for *most transactions*"
This suggests to me that most tx will occur off-block with the block chain
used for settlement. Indeed Satoshi was working on a trust based market
before he left.
If commerce works well enough off-block with zero trust settlement
supporting it, people might even forget that the block chain exists, like
with gold settlement. But it can be used for transactions. To this end I
welcome higher fees, so that the block chain becomes the reserve currency
of the internet and is used sparingly.
But as Gavin pointed out, bitcoin is still an experiment and we are all
still learning. We are also learning from alt coin mechanisms. I am
unsure there is huge urgency here, and would lean towards caution as
bitcoin infrastructure rapidly grows.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150514/14a689aa/attachment.html>

2023-06-07 15:32:52

- reply

📅 Original date posted:2015-05-01
📝 Original message:On 2 May 2015 at 00:57, Marc D. Wood <metamarc at metamarket.biz> wrote:
> METAmarket: Trustless Federated Marketplaces
> >>> http://metamarket.biz <<<
>
> * * *
> Introduction
>
> METAmarket is an open source protocol and proof-of-concept reference
> client specifying a trustless federated marketplace which uses Bitcoin as
> a universal currency and Bitmessage as a P2P communication network.
> Time-locked refund transactions ensure that incentives are aligned toward
> completing the trade without the need for trusted third parties. Systemic
> vulnerabilities such as transaction malleability are mitigated through the
> use of a federated reputation model. This document is a non-technical
> overview of how the METAmarket client and protocol work. For more
> technical details, see the protocol specification.
>
> Motivation
>
> Overly centralized marketplaces and payment services extract high fees,
> impose and abuse excessive control and remove any hope of privacy from
> users. As more commerce moves online, many consumers may find their
> lifetime history of purchases (including books, personal items and
> location details) for sale to advertisers, employers, curious neighbors,
> stalkers, political opponents and government agencies. An ideal system
> would be one of secure private transactions directly between buyer and
> seller without middle men collecting data or adding fees. Such systems are
> now feasible by combining recently developed technologies for anonymous
> decentralized payment and messaging systems.
>
> Client
>
> To use the marketplaces, a client application which implements the
> METAmarket protocol is required. The client is used to post, browse and
> execute trades. It also requires a Bitcoin Core wallet to handle payments
> and refunds. A working client is available at:
>
> http://github.com/metamarcdw/metamarket
>
Is there any relation between this and the work satoshi was putting into
the core before he left?
https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150502/aed666ab/attachment.html>

2023-06-07 15:27:11

- reply

📅 Original date posted:2014-11-08
📝 Original message:On 8 November 2014 16:28, Daniel F <nanotube at gmail.com> wrote:
> > But I'd like to know what storage, RAM and bandwidth resources are
> > needed. I guess that the problem is not the CPU.
>
> Hi Francis,
>
> Here are some rough guidelines for you, based on the statistics from my
> node:
>
> disk usage: about 30GB currently for the blockchain data. It'll only
> keep growing from here, but relatively slowly.
>
There's some statistics on this site:
https://blockchain.info/charts/blocks-size
It may be reasonable to assume 10GB growth a year. When I was running a
full node I gave it a disk of 50GB.
>
> cpu usage: pretty much nothing, after you have synced the blockchain.
>
> ram usage: after it runs for a few months, my node gets up to using 1.5
> GB of ram or so.
>
> bandwidth usage: my node averages about 500GB of traffic per month, most
> of it outgoing.
>
> Hope that gives you a rough idea of what you can expect for running full
> node.
>
> Best,
> Daniel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20141108/82dbada2/attachment.html>

2023-06-07 15:26:53

- reply

📅 Original date posted:2014-10-27
📝 Original message:On 27 October 2014 08:49, Wladimir <laanwj at gmail.com> wrote:
> On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
>
> > Firstly, apologies in coming in late to the conversation. As I am also
> > working on a REST API for electronic coins. Some questions:
> >
> > 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST
> output
> > e.g. the response format and MIME types. Or just compile from source?
>
> See the opening post from @jgarzik, it has some documentation on how
> to use the API.
>
> It would be nice to have some write-up about the current functionality
> in the release notes, but there currently is none.
>
> It's a RPC-side change, not a P2P-side change so it doesn't require a BIP.
>
Thanks. Yes, I worked this out after looking at the code.
I would be happy to help with documentation.
>
> > 2. How set in stone is v1 of the the going forward? PS I support
> @maaku's
> > comments re: "/api/v1/" -- tho I guess it is too late for that now.
> > 3. Would there be any support to develop this interface into something
> that
> > would be W3C standards compliant, or reviewed by the REST community. So
> for
> > example a context can be provided to self document the terms (something
> I've
> > almost completed) and would allow standardization of block explorer and
> > bitcoind outputs. Right now every explorer seems to have a different
> JSON
> > output.
>
> It's not too late, it's not been merged yet.
>
> Though a W3C standard takes a long time to pan out, and it may be more
> useful to have this available rather than wait for the API to be
> standardized (which means this will need to be postponed at least one
> version). As you say, a new interface be added later under another
> URI.
>
Agree. I think these changes are great for 0.10.
>
> Note that we're only interested in exposing read-only, public data
> which is already available in Bitcoin Core's internals.
> We're not aiming to add a fully-fledged block explorer with (say)
> address indexes. Although that could be part of the standard if it
> allows implementations to support just a subset.
>
Got it thanks.
>
> Anyhow - please coordinate this with Jeff Garzik, it's better to work
> together here.
>
Will do. Work in this area is ongoing, both in terms of
coding/patches/testing and documentation.
Do you think it would a reasonable idea to put down some thoughts and
proposals in a BIP?
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141027/9f26ee82/attachment.html>

2023-06-07 15:26:52

- reply

📅 Original date posted:2014-10-26
📝 Original message:On 26 October 2014 08:57, Wladimir <laanwj at gmail.com> wrote:
> Now that headers-first is merged it would be good to do a 0.10 release
> soon. Not *too* soon as a major code change like that takes some time
> to pan out, but I'd like to propose the following:
>
> - November 18: split off 0.10 branch, translation message and feature
> freeze
> - December 1: release 10.0rc1, start Release Candidate cycle
>
> That leaves three weeks until the freeze. After the release and branch
> split-off, the RC cycle will run until no critical problems are found.
> For major releases this is usually more painful than for stable
> releases, but if we can keep to these dates I'd expect the final
> release no later than January 2015.
>
> Let's aim to have any pending development for 0.10 merged before
> November 18. Major work that I'm aware of is:
>
> - BIP62 (#5134, #5065)
> - Verification library (#5086, #5118, #5119)
> - Gitian descriptors overhaul, so that Gitian depends = Travis depends
> (#4727)
> - Autoprune (#4701)
> - Add "warmup mode" for RPC server (#5007)
> - Add unauthenticated HTTP REST interface (#2844)
>
Thanks for the update.
I was even unaware of of #2844 : 'The beginnings of a block explorer-style
API for bitcoind.'
https://github.com/bitcoin/bitcoin/pull/2844
Seems to me like an important piece of work, Im glad it's finally made the
cut.
Firstly, apologies in coming in late to the conversation. As I am also
working on a REST API for electronic coins. Some questions:
1. Is there a BIP, or some other doc (e.g. gist), outlining the REST output
e.g. the response format and MIME types. Or just compile from source?
2. How set in stone is v1 of the the going forward? PS I support @maaku's
comments re: "/api/v1/" -- tho I guess it is too late for that now.
3. Would there be any support to develop this interface into something that
would be W3C standards compliant, or reviewed by the REST community. So
for example a context can be provided to self document the terms (something
I've almost completed) and would allow standardization of block explorer
and bitcoind outputs. Right now every explorer seems to have a different
JSON output.
Great work! Looking forward to seeing this go live and how it devlops!
>
> Let me know if there is anything else you think is ready (and not too
> risky) to be in 0.10. You can help along the development process by
> participating in testing and reviewing of the mentioned pull requests,
> or just by testing master and reporting bugs and regressions.
>
> Note: I intended the 0.10 release to be much sooner. The reason that
> this didn't pan out is that I insisted on including headers-first, and
> this took longer than expected. There seems to be a preference to
> switch to a fixed (instead of feature-based) 6-month major release
> schedule, ie
>
> - July 2015: 0.11.0 (or whatever N+1 release is called)
> - January 2016: 0.12.0 (or whatever N+2 release is called)
> - July 2016: 0.13.0 (or whatever N+3 release is called)
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/9b77e9de/attachment.html>

2023-06-07 15:26:50

- 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

- 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:43

- reply

📅 Original date posted:2014-10-31
📝 Original message:On 22 October 2014 23:54, Adam Back <adam at cypherspace.org> wrote:
> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
>
A very well written paper, thank you for putting it together and sharing.
Given it's the 6 year birthday of satoshi's white paper, I just read
through it again.
I find it interesting that bitcoin is never defined in Satoshi's paper,
indeed, it never appears after the first word.
The term Electronic Coin is defined.
The terminology of bitcoin / altcoin / altchain / blockchain in this paper
still leaves me slightly uneasy, and I try to use the terms electronic coin
and electronic cash, more often.
If satoshi were to come back and continue his work, would it be an altcoin,
would it be "The" blockchain, would it be bitcoin, or would what we know as
bitcoin become an alt. I suspect these questions are nothing more than
academic curiosity.
But I think I'll get more used to it over time :)
In any case, happy birthday "bitcoin" :)
>
> Adam
>
> On 16 March 2014 15:58, Adam Back <adam at cypherspace.org> wrote:
> > So an update on 1-way pegging (aka bitcoin staging, explained in quoted
> text
> > at bottom): it turns out secure 2-way pegging is also possible (with some
> > bitcoin change to help support it). The interesting thing is this allows
> > interoperability in terms of being able to move bitcoin into and out of a
> > side chain. The side chains may have some different parameters, or
> > experimental things people might want to come up with (subject to some
> > minimum compatibility at the level of being able to produce an SPV proof
> of
> > a given form).
> >
> > At the time of the 1-way peg discussion I considered 2-way peg as
> desirable
> > and it seemed plausible with bitcoin changes, but the motivation for
> 1-way
> > peg was to make it less risky to make changes on bitcoin, so that seemed
> > like a catch-22 loop. Also in the 2-way peg thought experiment I had not
> > realized how simple it was to still impose a security firewall in the
> 2-way
> > peg also.
> >
> >
> > So Greg Maxwell proposed in Dec last year a practically compact way to do
> > 2-way pegging using SPV proofs. And also provided a simple argument of
> how
> > this can provide a security firewall. (Security firewall means the
> impact
> > of security bugs on the side-chain is limited to the people with coins in
> > it; bitcoin holders who did not use it are unaffected). [1]
> >
> > How it works:
> >
> > 1. to maintain the 21m coins promise, you start a side-chain with no
> > in-chain mining subsidy, all bitcoin creation happens on bitcoin chain
> (as
> > with 1-way peg). Reach a reasonable hash rate. (Other semantics than
> 1:1
> > peg should be possible, but this is the base case).
> >
> > 2. you move coins to the side-chain by spending them to a fancy script,
> > which suspends them, and allows them to be reanimated by the production
> of
> > an SPV proof of burn on the side-chain.
> >
> > 3. the side-chain has no mining reward, but it allows you to mint coins
> at
> > no mining cost by providing an SPV proof that the coin has been
> suspended as
> > in 2 on bitcoin. The SPV proof must be buried significantly before being
> > used to reduce risk of reorganization. The side-chain is an SPV client
> to
> > the bitcoin network, and so maintains a view of the bitcoin hash chain
> (but
> > not the block data).
> >
> > 4. the bitcoin chain is firewalled from security bugs on the side chain,
> > because bitcoin imposes the rule that no more coins can be reanimated
> than
> > are currently suspend (with respect to a given chain).
> >
> > 5. to simplify what they hypothetical bitcoin change would need to
> consider
> > and understand, after a coin is reanimated there is a maturity period
> > imposed (say same as fresh mined coins). During the maturity period the
> > reanimation script allows a fraud proof to spend the coins back. A fraud
> > bounty fee (equal to the reanimate fee) can be offered by the mover to
> > incentivize side-chain full nodes to watch reanimations and search for
> fraud
> > proofs.
> >
> > 6. a fraud proof is an SPV proof with a longer chain showing that the
> proof
> > of burn was orphaned.
> >
> > There are a few options to compress the SPV proof, via Fiat-Shamir
> transform
> > to provide a compact proof of amount work contained in a merkle tree of
> > proofs of work (as proposed by Fabien Coelho link on
> > http://hashcash.org/papers/) with params like 90% of work is proven.
> But
> > better is something Greg proposed based on skip-lists organized in a
> tree,
> > where 'lucky' proofs of work are used to skip back further. (Recalling
> that
> > if you search for a 64-bit leading-0 proof-of-work, half the time you
> get a
> > 65-bit, quarter 66-bit etc.) With this mechanism you can accurately
> > prove the amount of proof of work in a compressed tree (rather than
> ~90%).
> >
> >
> > Apart from pegging from bitcoin to a side-chain, if a private chain is
> made
> > with same rules to the side-chain it becomes possible with some
> > modifications to the above algorithm to peg the side-chain to a private
> > chain. Private chain meaning a chain with the same format but signature
> of
> > single server in place of hashing, and timestamping of the block
> signatures
> > in the mined side chain. And then reactive security on top of that by
> full
> > nodes/auditors trying to find fraud proofs (rewrites of history relative
> to
> > side-chain mined time-stamp or approved double-spends). The reaction is
> to
> > publish a fraud proof and move coins back to the side chain, and then
> > regroup on a new server. (Open transactions has this audit + reactive
> model
> > but as far as I know does it via escrow, eg the voting pools for k of n
> > escrow of the assets on the private server.) I also proposed the same
> > reactive audit model but for auditable namespaces [4].
> >
> > Private chains add some possiblity for higher scaling, while retaining
> > bitcoin security properties. (You need to add the ability for a user to
> > unilaterally move his coins to the side-chain they came from in event the
> > chain server refuses to process transactions involving them. This
> appears
> > to be possible if you have compatible formats on the private chain and
> > side-chain).
> >
> >
> > This pegging discussion involved a number of #bitcoin-wizards, Greg
> Maxwell,
> > Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashjr.
> The
> > 2-way peg seems to have first been described by Greg. Greg thought of
> > 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2].
> > (As a ZK-SNARK could compactly prove full validation of a side chain
> rules).
> >
> > There was also something seemingly similar sounding but not described in
> > detail by Alex Mizrahi in the context of color coins in this post [3].
> >
> > Adam
> >
> > [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
> > [2] https://bitcointalk.org/index.php?topic=277389.40
> > [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
> > [4] http://www.cypherspace.org/p2p/auditable-namespace.html
> >
> > On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:
> >>
> >> Coming back to the staging idea, maybe this is a realistic model that
> >> could
> >> work. The objective being to provide a way for bitcoin to move to a
> live
> >> beta and stable being worked on in parallel like fedora vs RHEL or
> >> odd/even
> >> linux kernel versions.
> >>
> >> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin
> >> 0.x
> >> stable and leap-frogs as beta becomes stable after testing.
> >>
> >> Its a live beta, meaning real value, real contracts. But we dont want
> it
> >> to
> >> be an alt-coin with a floating value exactly, we want it to be bitcoin,
> >> but
> >> the bleeding edge bitcoin so we want to respect the 21 million coin
> limit,
> >> and allow coins to move between bitcoin and betacoin with some necessary
> >> security related restrictions.
> >>
> >> There is no mining reward on the betacoin network (can be merge mined
> for
> >> security), and the way you opt to move a bitcoin into the betacoin
> network
> >> is to mark it as transferred in some UTXO recognized way. It cant be
> >> reanimated, its dead. (eg spend to a specific recognized invalid
> address
> >> on
> >> the bitcoin network). In this way its not really a destruction, but a
> >> move,
> >> moving the coin from bitcoin to betacoin network.
> >>
> >> This respects the 21 million coin cap, and avoids betacoin bugs flowing
> >> back
> >> and affecting bitcoin security or value-store properties. Users may buy
> >> or
> >> swap betacoin for bitcoin to facilitate moving money back from betacoin
> to
> >> bitcoin. However that is market priced so the bitcoin network is
> security
> >> insulated from beta. A significant security bug in beta would cause a
> >> market freeze, until it is rectified.
> >>
> >> The cost of a betacoin is capped at one BTC because no one will pay more
> >> than one bitcoin for a betacoin because they could alternatively move
> >> their
> >> own coin. The reverse is market priced.
> >>
> >> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
> >> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
> >> bitcoins can be moved, and the old network switched off, with mining
> past
> >> a
> >> flag day moving to the betacoin.
> >>
> >> During the beta period betacoin is NOT an alpha, people can rely on it
> and
> >> use it in anger for real value transactions. eg if it enables more
> script
> >> features, or coin coloring, scalabity tweaks etc people can use it.
> >> Probably for large value store they are always going to prefer
> >> bitcoin-stable, but applications that need the coloring features, or
> >> advanced scripting etc can go ahead and beta.
> >>
> >> Bitcoin-stable may pull validated changes and merge them, as a way to
> pull
> >> in any features needed in the shorter term and benefit from the betacoin
> >> validation. (Testing isnt as much validation as real-money at stake
> >> survivability).
> >>
> >> The arguments are I think that:
> >>
> >> - it allows faster development allowing bitcoin to progress features
> >> faster,
> >>
> >> - it avoids mindshare dilution if alternatively an alt-coin with a hit
> >> missing feature takes off;
> >>
> >> - it concentrates such useful-feature alt activities into one OPEN
> source
> >> and OPEN control foundation mediated area (rather than suspected land
> >> grabs on colored fees or such like bitcoin respun as a business model
> >> things),
> >>
> >> - maybe gets the developers that would've been working on their pet
> >> alt-coin, or their startup alt-coin to work together putting more
> >> developers, testers and resources onto something with open control
> (open
> >> source does not necessarily mean that much) and bitcoin mindshare
> >> branding, its STILL bitcoin, its just the beta network.
> >>
> >> - it respects the 21 million limit, starting new mining races probably
> >> dillutes the artificial scarcity semantic
> >>
> >> - while insulating bitcoin from betacoin security defects (I dont mean
> >> betacoin as a testnet, it should have prudent rigorous testing like
> >> bitcoin, just the very act of adding a feature creates risk that
> bitcoin
> >> stable can be hesitant to take).
> >>
> >> Probably the main issue as always is more (trustable) very high caliber
> >> testers and developers. Maybe if the alt-coin minded startups and
> >> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
> >> bits they are missing, we'll get more hands to work on something of
> >> reusable
> >> value to humanity, in parallel with their startup's objectives and as a
> >> way
> >> for them to get their needed features, while giving back to the bitcoin
> >> community, and helping bitcoin progress faster.
> >>
> >> Maybe bitcoin foundation could ask for BTC donations to hire more
> >> developers
> >> and testers full time. $1.5b of stored value should be interested to
> safe
> >> guard their value store, and develop the transaction features.
> >>
> >> Adam
> >>
> >> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> >>>
> >>> This is exactly what I was planning to do with the
> >>> inappropriately-named "Ultimate Blockchain Compression". [...]
> >>>
> >>> For it to really work, it's gotta be part of the mainnet validation
> >>> rules, but no way it can be evaluated realistically without some kind
> of
> >>> "staging".
> >>
> >>
> >>> On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> >>>
> >>> I think this is a very interesting idea. As Bitcoiners, we often stuff
> >>> things into the 'alt chain' bucket in our heads; I wonder if this idea
> >>> works better as a curing period, essentially an extended version of
> the
> >>> current 100 block wait for mined coins.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20141031/b00e6945/attachment.html>

2023-06-07 15:26:26

- 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

- 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:26:01

- reply

📅 Original date posted:2014-09-27
📝 Original message:On 27 September 2014 15:56, Wladimir <laanwj at gmail.com> wrote:
> Bitcoin Core version 0.9.3 is now available from:
>
> https://bitcoin.org/bin/0.9.3/
>
> This is a new minor version release, bringing only bug fixes and updated
> translations. Upgrading to this release is recommended.
>
> Please report bugs using the issue tracker at github:
>
> https://github.com/bitcoin/bitcoin/issues
>
> Upgrading and downgrading
> ==========================
>
> How to Upgrade
> --------------
>
> If you are running an older version, shut it down. Wait until it has
> completely
> shut down (which might take a few minutes for older versions), then run the
> installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
> or
> bitcoind/bitcoin-qt (on Linux).
>
> If you are upgrading from version 0.7.2 or earlier, the first time you run
> 0.9.3 your blockchain files will be re-indexed, which will take anywhere
> from
> 30 minutes to several hours, depending on the speed of your machine.
>
> Downgrading warnings
> --------------------
>
> The 'chainstate' for this release is not always compatible with previous
> releases, so if you run 0.9.x and then decide to switch back to a
> 0.8.x release you might get a blockchain validation error when starting the
> old release (due to 'pruned outputs' being omitted from the index of
> unspent transaction outputs).
>
> Running the old release with the -reindex option will rebuild the
> chainstate
> data structures and correct the problem.
>
> Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
> the blockchain for missing spent coins, which will take a long time (tens
> of minutes on a typical machine).
>
> 0.9.3 Release notes
> =======================
>
> RPC:
> - Avoid a segfault on getblock if it can't read a block from disk
> - Add paranoid return value checks in base58
>
> Protocol and network code:
> - Don't poll showmyip.com, it doesn't exist anymore
> - Add a way to limit deserialized string lengths and use it
> - Add a new checkpoint at block 295,000
> - Increase IsStandard() scriptSig length
> - Avoid querying DNS seeds, if we have open connections
> - Remove a useless millisleep in socket handler
> - Stricter memory limits on CNode
> - Better orphan transaction handling
> - Add `-maxorphantx=<n>` and `-maxorphanblocks=<n>` options for
> control over the maximum orphan transactions and blocks
>
> Wallet:
> - Check redeemScript size does not exceed 520 byte limit
> - Ignore (and warn about) too-long redeemScripts while loading wallet
>
> GUI:
> - fix 'opens in testnet mode when presented with a BIP-72 link with no
> fallback'
> - AvailableCoins: acquire cs_main mutex
> - Fix unicode character display on MacOSX
>
> Miscellaneous:
> - key.cpp: fail with a friendlier message on missing ssl EC support
> - Remove bignum dependency for scripts
> - Upgrade OpenSSL to 1.0.1i (see
> https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no
> critical issues for Bitcoin Core)
> - Upgrade miniupnpc to 1.9.20140701
> - Fix boost detection in build system on some platforms
>
> Credits
> --------
>
> Thanks to everyone who contributed to this release:
>
> - Andrew Poelstra
> - Cory Fields
> - Gavin Andresen
> - Jeff Garzik
> - Johnathan Corgan
> - Julian Haight
> - Michael Ford
> - Pavel Vasin
> - Peter Todd
> - phantomcircuit
> - Pieter Wuille
> - Rose Toomey
> - Ruben Dario Ponticelli
> - shshshsh
> - Trevin Hofmann
> - Warren Togami
> - Wladimir J. van der Laan
> - Zak Wilcox
>
> As well as everyone that helped translating on
> [Transifex](https://www.transifex.com/projects/p/bitcoin/).
>
Great work!
Apologies if this has been covered. But I was curious about:
- Increase IsStandard() scriptSig length
Is there some place I read more to understand this change?
>
>
> ------------------------------------------------------------------------------
> 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://pubads.g.doubleclick.net/gampad/clk?id=154622311&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/20140927/036469f3/attachment.html>

2023-06-07 15:25:45

- 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:24:02

- reply

📅 Original date posted:2014-07-17
📝 Original message:I noticed this article today.
GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit
http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/
Here's a quote from Satoshi when the mining arms race began:
"We should have a gentleman’s agreement to postpone the GPU arms race as
long as we can for the good of the network. It’s much easer to get new
users up to speed if they don’t have to worry about GPU drivers and
compatibility. It’s nice how anyone with just a CPU can compete fairly
equally right now."
Maybe outdated now, but I thought it was interesting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140717/bee49012/attachment.html>

2023-06-07 15:20:45

- 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:20:28

- reply

📅 Original date posted:2014-04-27
📝 Original message:On 27 April 2014 09:07, Timo Hanke <timo.hanke at web.de> wrote:
> I'd like to put the following draft of a BIP up for discussion.
>
> Timo
>
> # Abstract
> There are incentives for miners to find cheap, non-standard ways to
> generate new work, which are not necessarily in the best interest of the
> protocol.
> In order to reduce these incentives this proposal re-assigns 2 bytes from
> the version field of the block header to a new extra nonce field.
> # Copyright
> # Specification
> The block version number field in the block header is reduced in size from
> 4 to 2 bytes.
> The third and fourth byte in the block header are assigned to the new
> extra nonce field inside the block header.
> # Motivation
> The motivation of this proposal is to provide miners with a cheap
> constant-complexity method to create new work that does not require
> altering the transaction tree.
>
> Furthermore, the motivation is to protect the version and timestamp fields
> in the block header from abuse.
> # Rationale
> Traditionally, the extra nonce is part of the coinbase field of the
> generation transaction, which is always the very first transaction of a
> block.
> After incrementing the extra nonce the minimum amount of work a miner has
> to do to re-calculate the block header is a) to hash the coinbase
> transaction and b) to re-calculate the left-most branch of the merkle tree
> all the way to the merkle root.
> This is necessary overhead a miner has to do besides hashing the block
> header itself.
> We shall call the process that leads to a new block header from the same
> transaction set the _pre-hashing_.
>
> First it should be noted that the relative cost of pre-hashing in its
> traditional form depends
> on the block size, which may create an unwanted incentive for miners
> to keep the block size small. However, this is not the main motivation for
> the current proposal.
>
> While the block header is hashed by ASICs, pre-hashing typically happens
> on a CPU because of the greater flexibility required.
> Consequently, as ASIC cost per hash performance drops the relative cost of
> pre-hashing increases.
>
> This creates an incentive for miners to find cheaper ways to create new
> work than by means of pre-hashing.
> An example of this currently happening is the on-device rolling of the
> timestamp into the future.
> These ways of creating new work are unlikely to be in the best interest of
> the protocol.
> For example, rolling the timestamp faster than the real time is unwanted
> (more so on faster blockchains).
>
> The version number in the block header is a possible target for alteration
> with the goal of cheaply creating new work.
> Currently, blocks with arbitrarily large version numbers get relayed and
> accepted by the network.
> As this is unwanted behaviour, there should not exist any incentive for a
> miner to abuse the version number in this way.
>
> The solution is to reduce the range of version numbers from 2^32 to 2^16
> and to declare the third and forth bytes of the block header as legitimate
> space for an extra nonce.
> This will reduce the incentive for a miner to abuse the shortened version
> number by a factor in the order of 2^16.
>
> As a side effect, this proposal greatly reduces the bandwidth requirements
> of a blind pool protocol by only submitting the block header to the miner.
> # Backwards Compatibility
> Old versions of the client will accept blocks of this kind but will throw
> an alert at the user to upgrade.
> The only code change would be a cast of the version number to a short.
> Besides the upgrade alert, old and new versions of the client can co-exist
> and there is no need to introduce a new block version number or to
> phase-out old block versions.
> # Reference Implementation
> # Final implementation
>
If changing the structure of the block header, wouldnt you also need to
increment the version number to 3?
>
> --
> Timo Hanke
> PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> 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/20140427/2ebc89a7/attachment.html>

2023-06-07 15:18:39

- reply

📅 Original date posted:2014-04-16
📝 Original message:On 16 April 2014 10:14, Wladimir <laanwj at gmail.com> wrote:
> Hello,
>
> Today I noticed that even my bank is warning people to not do internet
> banking with Windows XP.
>
> If it is no longer secure enough for online banking it's CERTAINLY not
> secure enough to run a wallet (for a node only it would be ok-ish as they
> have no keys to protect).
> Any opinions on what to do here? Just warn and allow the user to continue?
> Redirect them to a 'Windows XP is dangerous' message on bitcoin.org?
> (Microsoft uses
> http://windows.microsoft.com/en-us/windows/end-support-help)
>
> The drawback of dropping XP support completely would be that a lot of
> computers (especially in China and Russia etc) are still running XP, so
> this could cause the network to lose nodes.
>
XP with a trezor would work fine tho?
My personal preference would be a warning, and to direct them to a free
software operating system that they could upgrade to.
>
> If you're maintainer of other wallet software: how are you handling this?
> Are you going to drop XP support completely? If so, starting from when?
>
> Regards,
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> 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/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/20140416/35d4f081/attachment.html>

2023-06-07 15:15:54

- reply

📅 Original date posted:2014-03-20
📝 Original message:On 20 March 2014 02:41, Odinn Cyberguerrilla <
odinn.cyberguerrilla at riseup.net> wrote:
> I wish to state that I fundamentally disagree with this proposal of use
> cases for W3C payments workshop. Please read my following explanation and
> then do what you will:
>
> At one time I was invited to join the Web Payments conference calls. I
> considered it and then declined due to the very CLAs that Brent mentioned
> in the message that started this thread.
>
> I was trying to remember the language that I objected to relating to the
> W3C CLA. Found it: https://web-payments.org/minutes/ As mentioned, I was
> offered to join these calls but I declined due to, in part, the following:
> Upon review of the page at web-payments.org, I noticed that it provides
> a means to connect with web payments group by teleconference. However,
> there is an agreement that the site would require me to accept merely to
> join the teleconference and collaborate with others in the web payments
> group. I would say "unfortunately," but in my case I will say
> fortunately, I don't agree with the required agreement as shown here at
> http://www.w3.org/community/about/agreements/cla/ which is shown as
> follows at https://web-payments.org/minutes/ "There are no costs
> associated with joining the group or limitations on who may join the
> teleconference as long as they agree to the Web Payments community "
>
> Some of the things I don't like about the proposed agreement /
> "requirement" are fundamental. At the core, it should be understood that
> collaborative efforts, or teleconferences involving innovators who strive
> to develop concepts for eventual development of a social good, for
> example, should not be subject to a "requirement" that anyone agree to a
> license in relation to their participation or contribution. Such
> "requirements" inhibit innovation and free thought. For example, the web
> payments group provides that in order for me to participate, I must first
> "agree to license my Essential Claims under the W3C CLA RF Licensing
> Requirements" and numerous other requirements.
>
> Although I was interested in some sort of collaboration with the Web
> Payments Community Group, these CLAs - lengthy, burdensome, and in my
> personal view, highly dubious and potentially restricting with respect to
> innovation and free thought - caused me to reconsider, and thus I will not
> be entering into web or telephone conferences or related collaborations
> with the W3C / Web Payments folks until such time as they remove these
> burdensome requirements which are applied merely to join a call.
>
Fair point, but you need to understand that all specs created by the W3C
are committed to be royalty free. That's why there's a CLA, but I can
totally see if you or your employer feels uncomfortable with that. You
might have the best possible interests, but not everyone may be as honest.
Personally, have participated as an unaffiliated volunteer and hobbyist at
the W3C for a few years, I've never seen an issue with this. In fact, I'm
really happy that they have a bullet proof intellectual property framework
that guarantees all my contributions will never be encumbered by patents or
be charged royalties for.
>
> > Hello Bitcoiners,
> >
> > I have been working on some use cases for the W3C payments workshop. I'd
> > like to include Bitcoin, but I might not have the time:
> >
> > Here is what I have:
> >
> > https://www.w3.org/community/webpayments/wiki/WebPaymentsMobileUseCases
> >
> > Which is editable with a w3c username and password. Just be a member of
> > the
> > webpayments community group: http://www.w3.org/community/webpayments/
> >
> > More formally you can submit a pull request to:
> >
> > https://github.com/w3c-webmob/payments-use-cases
> >
> > -------------
> >
> > Due to discussions with others am attempting to apply the following
> > template:
> >
> >
> > Name: name of the solution
> > Use Cases: Key use cases for the solution
> > Regions and currencies: Any SDKs or APIs which are available to
> developers
> >
> > with the following things to consider (for use cases):
> > (1) add real money to the service
> > (2) buy a physical good in the real wold (e.g., a cup of coffee)
> > (3) pay for physical service (e.g., gym membership)?
> > (4) convert virtual money back into paper money
> > (5) transfer money from one person to another (even if the second person
> > is
> > not signed up for the service)?
> > (6) buy product online
> > (7) resolve disputes?
> > (8) view transactions?
> > (9) secure the wallet
> > (10) etc.
> >
> > Thanks for your time and have a great day!
> >
> > -Brent Shambaugh
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
>
>
> ------------------------------------------------------------------------------
> 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/20140320/75b1eebc/attachment.html>

2023-06-07 15:15:34

- 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:13:43

- reply

📅 Original date posted:2014-02-16
📝 Original message:On 27 December 2013 19:05, Mike Hearn <mike at plan99.net> wrote:
> For a long time the only block explorer for testnet has been the original
> blockexplorer.com, which is unfortunately often broken / behind / slow
> and not really maintained any more.
>
> There is now a new one, here:
>
> https://www.biteasy.com/testnet/blocks
>
> There's also a REST/JSON API for it.
>
> Please note one curiosity of this block explorer is that the coinbase tx
> doesn't necessarily come first in the listing (it's sorted by "time
> received", see).
>
> Other interesting thing to note: this site is built using bitcoinj. The
> author can be contacted on IRC sometimes using the nick damethos.
>
Some more information on testnet3 explorers ...
Here is a free software testnet explorer based on javascript/node
http://test.bitcore.io/
I've been working on a testnet explorer, but I think I will fork this and
add semantic web style markup attributes to the HTML.
Also a message I got from blockr.io "yes testnet will be added. I cannot
give you an estimate on when, but it'll probably happen in couple of weeks
(hopefully sooner)."
>
>
> ------------------------------------------------------------------------------
> 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/20140216/dd6344fe/attachment.html>

2023-06-07 15:11:25

- 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:11:23

- reply

📅 Original date posted:2014-01-01
📝 Original message:On 1 January 2014 19:33, Mike Hearn <mike at plan99.net> wrote:
> Bitcoin had an incredible year in 2013, and I very much enjoyed working
> with and meeting you all.
>
> I'm very much looking forward to some of the upgrades coming in 2014.
> Though a lot happened in the general community, last year was kind of quiet
> with respect to the core software. I'm hoping this year we can pick up the
> pace a little.
>
Happy new year! Thanks for your awesome contribution and to all those that
contributed to development.
"Bitcoin" was one of the 100 most searched for terms in 2013, really
looking forward to 2014!
>
> Cheers!
>
>
> ------------------------------------------------------------------------------
> 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/20140101/0a03d2a7/attachment.html>

2023-06-07 15:11:08

- reply

📅 Original date posted:2013-12-27
📝 Original message:On 27 December 2013 19:08, Mike Belshe <mike at belshe.com> wrote:
> Great!
>
> There is another one at http://testnet.btclook.com/ which provides a
> different view as well.
>
And another at:
http://test.webbtc.com/<http://test.webbtc.com/address/myTPjxggahXyAzuMcYp5JTkbybANyLsYBW>
Testnet does not currently fully function with for creating transactions:
http://test.webbtc.com/<http://test.webbtc.com/address/myTPjxggahXyAzuMcYp5JTkbybANyLsYBW>
Because there's no "unspent" API for getting the unspent values for an
address. If there existed a testnet explorer which would send out those
values (as blockchain.info does with the main net), that would be awesome.
I'm also working on a testnet explorer with semantic web markup so that
it's both human and machine readable.
>
> Mike
>
>
>
> On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> For a long time the only block explorer for testnet has been the original
>> blockexplorer.com, which is unfortunately often broken / behind / slow
>> and not really maintained any more.
>>
>> There is now a new one, here:
>>
>> https://www.biteasy.com/testnet/blocks
>>
>> There's also a REST/JSON API for it.
>>
>> Please note one curiosity of this block explorer is that the coinbase tx
>> doesn't necessarily come first in the listing (it's sorted by "time
>> received", see).
>>
>> Other interesting thing to note: this site is built using bitcoinj. The
>> author can be contacted on IRC sometimes using the nick damethos.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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/20131227/ec348462/attachment.html>

2023-06-07 15:10:46

- reply

📅 Original date posted:2013-12-15
📝 Original message:Harry and David suggested I send a message to this group. I was wondering
if the crypto group may consider adding support for *secp256k1* in the
browser Named Curve dictionary.
http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary
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"
};
Over the last year, there has been a significant increase in deployment for
this curve. It's used in bitcoin and many other crypto currencies.
Bitcoin deployment now numbers in the millions of users and hundreds of
companies. There are also free software implementations in most
languages.
For more background on Koblitz curve used by bitcoin see:
https://bitcointalk.org/?topic=2699.0
I'm aware that the API tends to expose what's existing in NSS, but, imho,
if it were possible to add support for this curve would be a great step to
help to many people that already work with crypto currencies in the browser.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131215/c4e0d373/attachment.html>

2023-06-07 15:10:23

- reply

📅 Original date posted:2013-12-06
📝 Original message:On 6 November 2013 07:41, slush <slush at centrum.cz> wrote:
> > But where are the private keys stored? Crypto in the browser with help,
> but although they will expose ECC via the NSS, I dont think bitcoin's
> particular curve will be supported, because it's not NIST approved. If the
> use case was presented though, they may add it.
>
> Trezor, my friend.
>
Looking forward to the trezor release, best of luck.
This may be an interesting read too:
https://www.grc.com/sqrl/sqrl.htm
> Slush
>
> Sent from mobile phone.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131206/dab65908/attachment.html>

2023-06-07 15:09:53

- reply

📅 Original date posted:2013-11-21
📝 Original message:On 14 October 2013 20:08, Adam Back <adam at cypherspace.org> wrote:
> Coming back to the staging idea, maybe this is a realistic model that could
> work. The objective being to provide a way for bitcoin to move to a live
> beta and stable being worked on in parallel like fedora vs RHEL or odd/even
> linux kernel versions.
>
> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
> stable and leap-frogs as beta becomes stable after testing.
>
> Its a live beta, meaning real value, real contracts. But we dont want it
> to
> be an alt-coin with a floating value exactly, we want it to be bitcoin, but
> the bleeding edge bitcoin so we want to respect the 21 million coin limit,
> and allow coins to move between bitcoin and betacoin with some necessary
> security related restrictions.
>
> There is no mining reward on the betacoin network (can be merge mined for
> security), and the way you opt to move a bitcoin into the betacoin network
> is to mark it as transferred in some UTXO recognized way. It cant be
> reanimated, its dead. (eg spend to a specific recognized invalid address
> on
> the bitcoin network). In this way its not really a destruction, but a
> move,
> moving the coin from bitcoin to betacoin network.
>
> This respects the 21 million coin cap, and avoids betacoin bugs flowing
> back
> and affecting bitcoin security or value-store properties. Users may buy or
> swap betacoin for bitcoin to facilitate moving money back from betacoin to
> bitcoin. However that is market priced so the bitcoin network is security
> insulated from beta. A significant security bug in beta would cause a
> market freeze, until it is rectified.
>
> The cost of a betacoin is capped at one BTC because no one will pay more
> than one bitcoin for a betacoin because they could alternatively move their
> own coin. The reverse is market priced.
>
> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
> bitcoins can be moved, and the old network switched off, with mining past a
> flag day moving to the betacoin.
>
> During the beta period betacoin is NOT an alpha, people can rely on it and
> use it in anger for real value transactions. eg if it enables more script
> features, or coin coloring, scalabity tweaks etc people can use it.
> Probably for large value store they are always going to prefer
> bitcoin-stable, but applications that need the coloring features, or
> advanced scripting etc can go ahead and beta.
>
> Bitcoin-stable may pull validated changes and merge them, as a way to pull
> in any features needed in the shorter term and benefit from the betacoin
> validation. (Testing isnt as much validation as real-money at stake
> survivability).
>
> The arguments are I think that:
>
> - it allows faster development allowing bitcoin to progress features
> faster,
>
> - it avoids mindshare dilution if alternatively an alt-coin with a hit
> missing feature takes off;
>
> - it concentrates such useful-feature alt activities into one OPEN source
> and OPEN control foundation mediated area (rather than suspected land
> grabs on colored fees or such like bitcoin respun as a business model
> things),
>
> - maybe gets the developers that would've been working on their pet
> alt-coin, or their startup alt-coin to work together putting more
> developers, testers and resources onto something with open control (open
> source does not necessarily mean that much) and bitcoin mindshare
> branding, its STILL bitcoin, its just the beta network.
>
> - it respects the 21 million limit, starting new mining races probably
> dillutes the artificial scarcity semantic
>
> - while insulating bitcoin from betacoin security defects (I dont mean
> betacoin as a testnet, it should have prudent rigorous testing like
> bitcoin, just the very act of adding a feature creates risk that bitcoin
> stable can be hesitant to take).
>
> Probably the main issue as always is more (trustable) very high caliber
> testers and developers. Maybe if the alt-coin minded startups and
> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
> bits they are missing, we'll get more hands to work on something of
> reusable
> value to humanity, in parallel with their startup's objectives and as a way
> for them to get their needed features, while giving back to the bitcoin
> community, and helping bitcoin progress faster.
>
> Maybe bitcoin foundation could ask for BTC donations to hire more
> developers
> and testers full time. $1.5b of stored value should be interested to safe
> guard their value store, and develop the transaction features.
>
I think there may be a simpler way to do this.
Create a new genesis block for a staging network, but in all other aspects,
as far as possible, keep the properties the same as bitcoin.
Do not actively be opposed to it being traded, but people need to know
that, although there is no intention to reset the chain, new and
potentially not fully tested, changes can be rolled into the network.
Anyone mining staging coins should be prepared for the value to go to zero.
Perhaps also a "straw poll" voting system could be set up for those that
own staging coins could sign messages saying which patches they would like
to test out next. When patches are stable in the staging area, they could
be "promoted" to the main net ...
>
> Adam
>
> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> > This is exactly what I was planning to do with the
> > inappropriately-named "Ultimate Blockchain Compression". [...]
> >
> > For it to really work, it's gotta be part of the mainnet validation
> > rules, but no way it can be evaluated realistically without some kind
> of
> > "staging".
>
> > On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> >
> > I think this is a very interesting idea. As Bitcoiners, we often stuff
> > things into the 'alt chain' bucket in our heads; I wonder if this idea
> > works better as a curing period, essentially an extended version of the
> > current 100 block wait for mined coins.
>
>
> ------------------------------------------------------------------------------
> 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=60134071&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/20131121/61f2374a/attachment.html>

2023-06-07 15:09:43

- reply

📅 Original date posted:2013-11-14
📝 Original message:On 15 November 2013 01:37, Daniel F <nanotube at gmail.com> wrote:
> > This is a decentralized currency, and we should avoid centralizing
> > decisions. This is something that impacts the community at large, and
> > deserves input and discussion at every level.
> >
> > I would suggest posting on all possible forums "proposal: switch to
> > uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
> > is generated. If the support is broad, it will be plain from the
> > responses if there is a consensus. Perhaps everyone will agree it is
> > the best course, and we can make an easy change.
> >
> > But we need less "core dev fiat" not more :)
> >
> this seems like such a paint-the-bikeshed problem that it's sure to
> generate vast volumes of discussion, waste a lot of people's time, and
> all for only a dubious (imo) gain. (case in point - here i am
> contributing to it :) ).
>
> i agree that we should avoid centralizing this. i'll go a step further
> and note that the client already has a dropdown allowing individuals to
> choose units. merchants are free to choose to price in different units.
> exchanges are free to denominate trade in different units.
>
> i suggest we just let the market do its thing and not get into trying to
> 'make a decision' of any sort.
>
I do agree with you here
e.g. I think the question of the ISO code (XBT vs BTC) is probably out of
scope for this thread, and there was no clear consensus, when it came up on
the forums.
As a data point, the price of bitcoin has gone up roughly 1000x since
satoshi made his suggestion that the decimal point could move 3 places.
I dont think it's a question of centralization, I was just seeking opinion
on what people felt about the reference implementation. How about just
changing the default value in the dropdown from BTC -> to mBTC
The the other clients and exchange choose whether they want to follow suit
or not
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&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/20131115/5cd8c304/attachment.html>

2023-06-07 15:09:30

- 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:09:08

- reply

📅 Original date posted:2013-11-06
📝 Original message:On 6 November 2013 06:33, kjj <bitcoin-devel at jerviss.org> wrote:
> One of the things that really gets me going is when someone devises a
> model, tests it against itself, and then pretends that they've learned
> something about the real world.
>
> Naturally, the Selfish Mining paper is exactly this sort of nonsense.
> Their model is one with no latency, and one where the attacker has total
> visibility across the network. An iterated FSM is not a suitable
> simulation of the bitcoin system. The bitcoin network does not have
> states, and to the extent that you can pretend that we do, you can't
> simulate transitions between them with static probabilities.
>
> The authors understand this deep down inside, even though they didn't
> work out the implications. They handwave the issue by assuming a total
> sybil attack, and in true academic spirit, they don't realize that the
> condition necessary for the attack is far, far worse than the attack
> itself.
>
> Greg said he'd like to run some simulations, and I'm thinking about it
> too. Unfortunately, he is busy all week, and I'm lazy (and also busy
> for most of tomorrow).
>
> If neither of us get to it first, I'm willing to pitch in 1 BTC as a
> bounty for building a general bitcoin network simulator framework. The
> simulator should be able to account for latency between nodes, and
> ideally within a node. It needs to be able to simulate an attacker that
> owns varying fractions of the network, and make decisions based only on
> what the attacker actually knows. It needs to be able to simulate this
> "attack" and should be generic enough to be easily modified for other
> crazy schemes.
>
> (Bounty offer is serious, but expires in one year [based on the earliest
> timestamp that my mail server puts on this email], and /may/ be subject
> to change if the price on any reputable exchange breaks 1000 USD per BTC
> in that period.)
>
> Basically, the lack of a decent network simulator is what allowed this
> paper to get press. If the author had been able to see the importance
> of the stuff he was ignoring, we wouldn't be wasting so much time
> correcting him (and sadly the reporters that have no way to check his
> claims).
>
> https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663
>
Thanks for posting this bounty. I'm interested in working on it, and will
give it a try. I also have some other commitments, so I suspect you guys
will finish it first tho... but if not, I'll post details of the simulator.
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&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/20131106/c5b726ae/attachment.html>

2023-06-07 15:08:30

- reply

📅 Original date posted:2013-11-06
📝 Original message:On 2 November 2013 22:14, Johnathan Corgan <johnathan at corganlabs.com> wrote:
> On 11/01/2013 10:01 PM, bitcoingrant at gmx.com wrote:
>
> > Server provides a token for the client to sign.
>
> Anyone else concerned about signing an arbitrary string? Could be a
> hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own
> randomly generated nonce, sign that, then pass the nonce and the
> signature back to the server for verification.
>
Good point.
There are actually times you may want to sign a transaction.
There's a little know HTTP code, 402, "Payment Required". We should really
start using this at some point ...
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Reserved for future use.[2] The original intention was that this code might
be used as part of some form of digital cash or micropayment scheme, but
that has not happened, and this code is not usually used. As an example of
its use, however, Apple's defunct MobileMe service generated a 402 error if
the MobileMe account was delinquent.[citation needed] In addition, YouTube
uses this status if a particular IP address has made excessive requests,
and requires the person to enter a CAPTCHA.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
>
>
> ------------------------------------------------------------------------------
> 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/20131106/0a43b210/attachment.html>

2023-06-07 15:08:30

- reply

📅 Original date posted:2013-11-06
📝 Original message:On 2 November 2013 22:57, slush <slush at centrum.cz> wrote:
> Glad to see that there are more and more people wanting to replace
> passwords with digital signatures.
>
> Although such method has been already used on other websites like Eligius
> or bitcoin-otc, I dont think theres any standard way to doing so yet.
>
> Two comments to your proposal:
>
> A) message-to-be-signed need to be carefully composed to be both
> structured and human readable. It should contain at least:
> Desired username/identity handler
> Server identifier (url)
> Timestamp to prevent replay attack
> Server challenge
>
> Then the user can see what he's signing, instead of signing some binary
> blob which can contain some evil data.
>
> B)
> Same structured data should be a part of html page in some header tag,
> ideally signed by server certificate to confirm that the request is valid.
> Then the login request can be processed by machine automatically, without a
> need of copy&paste by a user.
>
But where are the private keys stored? Crypto in the browser with help,
but although they will expose ECC via the NSS, I dont think bitcoin's
particular curve will be supported, because it's not NIST approved. If the
use case was presented though, they may add it.
This can actually be done today using client side certificates. Two
methods.
Method 1:
In your client side certificate, put in your bitcoin address in the
subjectAlternativeName field. This is a field that lets you tell the
server "I have another identity"
>From the bitcoin address look up via a ".well-known" key server some items
previously uploaded. This would normally be a signed value of the key
used, or a signed value of the the certificate. The server checks this and
logs you in.
Method 2:
In your client side certificate, put in an HTTP address. That HTTP address
contains your bitcoin address and a signed copy of your cert public key or
the cert itself.
The advantage here is that you dont need a key server.
Both methods work, I've been doing this kind of thing for 5 years+, and I'd
never go back to passwords on anything I build.
I'm all for recreating this UI in javascript too, but I just wonder how to
protect the private keys ...
> Slush
>
>
> On Sat, Nov 2, 2013 at 6:01 AM, <bitcoingrant at gmx.com> wrote:
>
>> Passwords are inefficient by design: frequently we hear news from Sony,
>> Square Enix, Adobe, and various others about passwords being compromised,
>> databases being copied and stolen. This story remains true in the Bitcoin
>> space. In light of the recent Bitcointalk forum breach echoes an increasing
>> need for passwords to become a thing of the past.
>>
>>
>>
>> In celebration of the 5 year anniversary of the Bitcoin whitepaper, we
>> are delighted to introduce the Message Signing based authentication method.
>>
>>
>>
>> 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://forums.bitcoingrant.org/
>>
>>
>>
>> Above is a proof of concept forum that utilize this authentication
>> method. Following Kerckhoffs's principle, this forum only stores the signed
>> message and bitcoin address the users provide the first time they use the
>> site, both are public information. In addition, there is no database,
>> everything is simply an RSS feed. For the sake of usability we have
>> included a redis for the sessions, at the cost of additional exposure to
>> potential risks: users no longer need to sign a token every time they wish
>> to post.
>>
>>
>>
>> All source code will be available on github in the next few days.
>>
>>
>>
>> We welcome any feedback or suggestions.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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/20131106/ad6ee9ff/attachment.html>

2023-06-07 15:08:26

- 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

- 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:52

- reply

📅 Original date posted:2013-10-24
📝 Original message:https://bitcoinfoundation.org/blog/?p=290
Very excited about this, particularly the 80 bytes embeddable message. I
do believe satoshi mentioned he wanted to add short messages, at some point.
Great work Gavin & all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/c4045d92/attachment.html>

2023-06-07 15:07:38

- 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

- 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:07:25

- reply

📅 Original date posted:2013-10-11
📝 Original message:On 1 April 2013 09:59, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
> I'm working on porting crypto currencies to the semantic web.
>
> The advantages of this is that pages can then become machine readable on
> the web allowing new types of innovation and spreading bitcoin information
> to a wider audience.
>
> The first step that needs to be done is to create a "vocabulary" for
> bitcoin.
>
> What this means is like a dictionary of terms that can be put down in a
> machine readable standard (called RDF).
>
> I was wondering if anyone has worked on this before or if there is a human
> readable "glossary" for bitcoin that I could take text from?
>
> seeAlso: https://bitcointalk.org/index.php?topic=163705.0
>
Hi All
Sorry for the delay on this. I've made a very simple start, and am hosting
the vocabulary at.
https://w3id.org/cc
Having chatted on IRC, I'm not only going to model bitcion, but all crypto
currencies in time, starting first with bitcoin. There's only one use case
currently support, which is a way to tell the semantic web that a link is a
bitcoin address (I know you can already introspect on the bitcoin: link but
introspection requires out of band knowledge). More explanation below:
*Use Case
*
As a publisher Alice would like to link her web page content (or app) to a
bitcoin address, so that donations can be received by those that have
enjoyed her work.
*Model
*
It's only a slight overhead to model all crypto currencies so perhaps the
model will be something like
URI -> crypto-currency-address -> bitcoin-address
*Implementation
*
The folks at w3id.org have kindly offered to user their permanent
identifier switchboard, then we redirect to a locked down vocabulary.
As an implementer you simply need to add a single rel= tag to your markup.
*Example Usage*
In a web page:
<*meta* rel="https://w3id.org/cc#bitcoin<https://w3id.org/cc#bitcoin-address>"
href="bitcoin:1234...." />
In an html5 app:
<a rel="https://w3id.org/cc#bitcoin <https://w3id.org/cc#bitcoin-address>"
href="bitcoin:1234...."></a>
*Note: you an provide context for an individual concept in HTML5 (as
opposed to the webpage itself), such as an app, a project, a person, but
using the @about tag.
*
For litecoins (coming soon)
<a rel="https://w3id.org/cc#litecoin <https://w3id.org/cc#litecoin-address>"
href="...."></a>
*Next Steps
*
It's just a small step to start with, can allow all sorts of entities to
start accepting bitcoin in a way that complies with the W3C best
practices. I'll be improving and extending this over time, feedback or
help is welcome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131011/13593de6/attachment.html>

2023-06-07 15:07:04

- reply

📅 Original date posted:2013-09-29
📝 Original message:On 29 September 2013 04:28, Neil Fincham <neil at asdf.co.nz> wrote:
> I subscribe to this list so I can keep up-to date with bitcoin
> development, can we keep philosophy and tax evasion out of it?
>
Hi Neil, perhaps I didnt present the use case clearly. It was not about
evasion, it was about voluntary donations going to the correct place, being
verified by an oracle. I dont wish to stray off topic, so I'll leave it at
that.
>
> Neil
>
>
> On 29 September 2013 09:15, <rob.golding at astutium.com> wrote:
>
>> > But the regulatory environment in many geographical regions in
>> > uncertain. Do we need to pay capital gains? Do we need to pay a
>> > sales taxs etc. etc.
>>
>> In most regions it's not only 'simple' but trivial - BTC is just
>> 'another currency' and accounted for exactly the same way - it doens't
>> matter if you sell your hose for GBP, USD, EUR, BTC or sacks of Pig
>> Dung, you still have a GBP tax issue ...
>>
>> > So my idea is to voluntarily pre empt legislation by giving donations
>> > to govt (aka taxation) for bitcoin service providers.
>>
>> You want to volunteer to pay tax ? I'd suggest stronger medication ...
>>
>> > However, there is something of a problem with voluntary donations.
>> > Most people are not satisfied with the way they are spent.
>>
>> 80% of 'donations' end up spent on 'adminsitration' and not what they
>> were donated for, this is a 'greed' issue not a 'currency' issue.
>>
>> > In the UK
>> > a recent survey said that only 18% of people thought that tax money
>> > was wisely spent.
>>
>> Tax isn't voluntary or a donation. The 18% who think UK tax is well
>> spent are the 18% of the population who get the tax money, not the 82%
>> that pay it ;)
>>
>> > Can we fix it?
>>
>> First we kill all the politicians ...
>>
>> > So let's say I run a business and I make 1 million euros. I wish to
>> > donate 10% of my profits to society. But let's say I dont want that
>> > money to go to wars of aggression, but rather, to the fire
>> > de[department.
>>
>> So give it to the FD - what you do with your post-tax profits are up to
>> you ;)
>>
>> > At this point everyone wins. The business person is happy to make a
>> > contribution. The govt. is happy that it gets more revenue. The
>> > fire dept. is happy that it has revenue to do its work. And
>> > everything has gone to the right place in a kind of democratic way.
>>
>> Where does gov't come into this ? I think you're confusing 'tax' which
>> you have zero control over and 'donations' which you already have 100%
>> control over.
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> 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=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> 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=60133471&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/20130929/4eafafab/attachment.html>

2023-06-07 15:07:03

- reply

📅 Original date posted:2013-09-29
📝 Original message:On 29 September 2013 10:32, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham <neil at asdf.co.nz> wrote:
>
>> I subscribe to this list so I can keep up-to date with bitcoin
>> development, can we keep philosophy and tax evasion out of it?
>>
>
> Yes, that's off-topic for this mailing list. Lets stick to technical
> issues that we can solve by writing code.
>
Hi Gavin, apologies if my post came across as off-topic. My aim was to
present a use case, and ask whether or not it was technically feasible
using smart contracts.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> 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=60133471&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/20130929/482050c2/attachment.html>

2023-06-07 15:07:01

- reply

📅 Original date posted:2013-09-27
📝 Original message:We all love bitcoin's ability to transfer value in real time across borders.
But the regulatory environment in many geographical regions in uncertain.
Do we need to pay capital gains? Do we need to pay a sales taxs etc. etc.
At this point bitcoin is small enough for this to not be a huge issue, but
one day that may change (maybe we hope!).
So my idea is to voluntarily pre empt legislation by giving donations to
govt (aka taxation) for bitcoin service providers.
However, there is something of a problem with voluntary donations. Most
people are not satisfied with the way they are spent. In the UK a recent
survey said that only 18% of people thought that tax money was wisely
spent. This is bad for govt., bad for people, and bad for the trusted
relationship.
Can we fix it? Maybe we smart contract and voluntary donations it's
possible!
So let's say I run a business and I make 1 million euros. I wish to donate
10% of my profits to society. But let's say I dont want that money to go
to wars of aggression, but rather, to the fire de[department.
So we set up a smart contract that is only "cashable" if the money goes to
the right place (verified by an oracle).
At this point everyone wins. The business person is happy to make a
contribution. The govt. is happy that it gets more revenue. The fire
dept. is happy that it has revenue to do its work. And everything has gone
to the right place in a kind of democratic way.
Over time if it takes off, this could provide revenue for many essential
services that are needed by people, in a way that allows more democratic
freedom of choice.
So my question is whether it may be possible to use smart contracts to
achieve a better democracy that is good for people, good for govt, and good
for innovation? My hope is that the answer is ...
"Yes We Can"
:)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130928/45394d5b/attachment.html>

2023-06-07 15:07:00

- reply

📅 Original date posted:2013-09-25
📝 Original message:On 25 September 2013 13:15, Mike Hearn <mike at plan99.net> wrote:
> It won't fit. But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or "download
> this file and do what you find there", it's no different unless there's
> potential for a MITM attack. If the request URL is HTTPS or a secured
> Bluetooth connection then there's no such possibility.
>
It depends on the attacker. I think a large entity such as a govt or big
to medium size corporation *may* be able to MITM https, of course the
incentive to do so is probably not there ...
>
>
>
>
> On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach <
> andreas at schildbach.de> wrote:
>
>> While it's good to save space, I'm at the moment not convinced that
>> taking a de-route via an URL is a good idea to begin with.
>>
>> The main problem is trust. If you scan a QR code from a foreign phone,
>> you trust that that phone is owned by the one you want to send money to.
>> By adding the HTTP request that trust is voided.
>>
>> As soon as there is a BIP70 implementation, I will begin playing with
>> putting the payment request directly into the QR code.
>>
>>
>> On 09/25/2013 11:27 AM, Mike Hearn wrote:
>> > We could also say that if protocol part (https://) is missing, it's
>> > implied automatically. So just:
>> >
>> > bitcoin:1abc........?r=bob.com/r/aZgR <http://bob.com/r/aZgR>
>> >
>> > I think that's about as small as possible without re-using the pubkey as
>> > a token in the url.
>> >
>> >
>> > On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <
>> gavinandresen at gmail.com
>> > <mailto:gavinandresen at gmail.com>> wrote:
>> >
>> > On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike at plan99.net
>> > <mailto:mike at plan99.net>> wrote:
>> >
>> > BTW, on the "make qrcodes more scannable" front -- is it too
>> > late to change BIP 72 so the new param is just "r" instead of
>> > "request"? Every byte helps when it comes to qrcodes ...
>> >
>> >
>> > Not too late, assuming there are no objections. Smaller QR codes is
>> > a very good reason to change it.
>> >
>> > --
>> > --
>> > Gavin Andresen
>> >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > 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=60133471&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> 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=60133471&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/20130925/55e2d8b1/attachment.html>

2023-06-07 15:05:59

- 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:05:57

- reply

📅 Original date posted:2013-08-15
📝 Original message:On 15 August 2013 02:29, Gavin Andresen <gavinandresen at gmail.com> wrote:
> It feels to me like we're close to a 0.9 "feature freeze" / start of
> release cycle; I'd like to talk a little bit about what we'd like to see in
> the final 0.9 release.
>
> My list:
>
> Bug: I'd really like to see the leveldb corruption issue (mostly on OSX,
> it seems) fixed. This is hard because it can't be reliably reproduced, and,
> at least on my machine, takes weeks to occur. Help needed to reproduce/fix,
> see https://github.com/bitcoin/bitcoin/issues/2770 for what we know about
> the problem.
>
> Payment Protocol support is ready to be pulled (
> https://github.com/bitcoin/bitcoin/pull/2539) . Unless there are major
> objections, I will pull it tomorrow (it has already gone through two rounds
> of bounty-driven QA testing, so I'm convinced it is ready).
>
> I'd love for 0.9 to contain sipa's "headers first" initial block download
> optimization; I think it is a big enough improvement to justify making the
> 0.9 test/release cycle longer.
>
> Coin control (https://github.com/bitcoin/bitcoin/pull/2343).
>
> The autotools work (https://github.com/bitcoin/bitcoin/pull/2805).
>
> Gitian-build with the latest openssl and Qt5. Perhaps update the version
> of Debian VMs that we gitian-build with.
>
> I plan on spending about half my time on code review and helping get pull
> requests tested, and the other half of my time working on code that
> probably won't make it into the 0.9 release.
>
+1
Sounds great!
>
> --
> --
> 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/20130815/930f652a/attachment.html>

2023-06-07 15:05:46

- reply

📅 Original date posted:2013-08-09
📝 Original message:On 9 August 2013 13:59, Wendell <w at grabhive.com> wrote:
> We have been discussing something like this over here too, as well as
> exploring more esoteric blockchain+signature-based "SSO" implementations as
> discussed by John Light and others.
>
I've been using SSO for years using an X.509 private key in my browser, and
my public key referenced in my home page.
The unfortunate thing is that X.509 tends to use RSA, and bitcoin tends to
use ECC for space reasons. Since, in its simplest form, bitcoin is a
distributed ledger of public key / balance values you could imagine an
enormous eco system where every key pair become a wallet with 10s of
millions of users.
I was thinking about an alt coin along these lines. The problem is that
there's no OP_CODE for RSA and the block chain would become massive.
>
> One of our long-term ambitions with Hive is to provide a (mostly)
> user-transparent, decentralized authentication service. It sounds like our
> infrastructure could already handle a Persona implementation, and we very
> much want to get behind some forward-thinking standard. So as long as the
> plan _IS_ to remove said 'centralized struts' at the appropriate time, I'd
> say we're interested in exploring this further.
>
Sounds great, would love to hear more about what you come up with!
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:
>
> > This is just me making notes for myself, I'm not seriously suggesting
> this be implemented any time soon.
> >
> > Mozilla Persona is an infrastructure for web based single sign on. It
> works by having email providers sign temporary certificates for their
> users, whose browsers then sign server-provided challenges to prove their
> email address.
> >
> > Because an SSO system is a classic chicken/egg setup, they run various
> fallback services that allow anyone with an email address to take part.
> They also integrate with the Google/Yahoo SSO systems as well. The
> intention being that they do this until Persona becomes big enough to
> matter, and then they can remove the centralised struts and the system
> becomes transparently decentralised.
> >
> > In other words, they seem to do a lot of things right.
> >
> > Of course you can already sign payments using an X.509 cert issued to an
> email address with v1 of the payment protocol, so technically no new PKI is
> needed. But the benefit of leveraging Persona would be convenience - you
> can get yourself a Persona cert and use it to sign in to websites with a
> single click, and the user experience is smart and professional. CAs in
> contrast are designed for web site admins really so the experience of
> getting a cert for an email address is rather variable and more heavyweight.
> >
> > Unfortunately Persona does not use X.509. It uses a custom thing based
> on JSON. However, under the hood it's just assertions signed by RSA keys,
> so an implementation is likely to be quite easy. From the users
> perspective, their wallet app would embed a browser and drive it as if it
> were signing into a website, but stop after the user is signed into Persona
> and a user cert has been provisioned. It can then sign payment requests
> automatically. For many users, it'd be just one click, which is pretty neat.
>
>
> ------------------------------------------------------------------------------
> 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/20130809/f309fcc6/attachment.html>

2023-06-07 15:05:45

- reply

📅 Original date posted:2013-08-09
📝 Original message:On 9 August 2013 14:08, Mike Hearn <mike at plan99.net> wrote:
> Bitcoin sought to reduce dependence on trusted third parties, where as,
>> persona is increasing the reach of trusted third parties. The keys and
>> passwords are stored on mozilla's servers, sometimes on your email
>> providers. Persona, is however, a progression and will hopefully improve
>> its security and decentralization as it goes along.
>>
>
> When Persona is supported by all the key players in a transaction Mozilla
> doesn't get anything, do they? You can easily run your own IDP on a
> personal server if you're the kind of person who likes to do that, then run
> Firefox so you have a native implementation and the Mozilla servers aren't
> involved. The keys never leave your computers.
>
You'd need to run your own email server and/or change email address, which
is not in the reach of the average user, and maybe not even of some
businesses.
>
> Whilst X.509 certs can indeed be issued for any arbitrary string, you
> still need a CA that will do it for you, and that's typically not so
> trivial. CAs aren't meant for widespread end user adoption, really, whereas
> Persona is.
>
You can self sign X.509 certificates quite easily (e.g. one click via
<KEYGEN>), then rely on a decentralized web of trust to remove browser
warnings. A few people are working on this.
>
> I don't think Persona is any more or less centralised than other PKIs,
> really, just easier to use. Ultimately the string you're verifying is a
> user at host pair, so the host is centralised via DNS and to verify the
> assertions it vends, you must use SSL to connect to it, so under the hood
> the regular SSL PKI is still there.
>
>
>
It is easier to use, that's a great plus. But convenience is often a trade
off with security.
I dont user user at host, I use my home page because it's easy to dereference
and get a public key. Email is hard to dereference.
Yes, there is a reliance on DNS, which Tim calls the 'Achilles heel' of the
web, but it's held up quite well so far (fortunately for us).
Mozilla also have a master key to most email accounts, so if anyone got
access to that they could impersonate the vast majority of users that have
not opted in. I would not use persona for financial stuff, but if I made a
casual app with non sensitive information it would be one of the top
choices, imho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130809/45364f00/attachment.html>

2023-06-07 15:05:44

- reply

📅 Original date posted:2013-08-09
📝 Original message:On 9 August 2013 13:43, Mike Hearn <mike at plan99.net> wrote:
> This is just me making notes for myself, I'm not seriously suggesting this
> be implemented any time soon.
>
> Mozilla Persona is an infrastructure for web based single sign on. It
> works by having email providers sign temporary certificates for their
> users, whose browsers then sign server-provided challenges to prove their
> email address.
>
> Because an SSO system is a classic chicken/egg setup, they run various
> fallback services that allow anyone with an email address to take part.
> They also integrate with the Google/Yahoo SSO systems as well. The
> intention being that they do this until Persona becomes big enough to
> matter, and then they can remove the centralised struts and the system
> becomes transparently decentralised.
>
> In other words, they seem to do a lot of things right.
>
> Of course you can already sign payments using an X.509 cert issued to an
> email address with v1 of the payment protocol, so technically no new PKI is
> needed. But the benefit of leveraging Persona would be convenience - you
> can get yourself a Persona cert and use it to sign in to websites with a
> single click, and the user experience is smart and professional. CAs in
> contrast are designed for web site admins really so the experience of
> getting a cert for an email address is rather variable and more heavyweight.
>
> Unfortunately Persona does not use X.509. It uses a custom thing based on
> JSON. However, under the hood it's just assertions signed by RSA keys, so
> an implementation is likely to be quite easy. From the users perspective,
> their wallet app would embed a browser and drive it as if it were signing
> into a website, but stop after the user is signed into Persona and a user
> cert has been provisioned. It can then sign payment requests automatically.
> For many users, it'd be just one click, which is pretty neat.
>
Persona, in it's current state, is the exact opposite of the principle
behind of bitcoin.
Bitcoin sought to reduce dependence on trusted third parties, where as,
persona is increasing the reach of trusted third parties. The keys and
passwords are stored on mozilla's servers, sometimes on your email
providers. Persona, is however, a progression and will hopefully improve
its security and decentralization as it goes along.
A (client or server side) X.509 cert can be issued to any address, be it
email, telephone, webpage, *or* to a bitcoin address, it allows any URI in
he subjectAlternativeName field. This is much more of bitcoin like model
where the private key sits on your client and the public key is in
discoverable by the other end.
Most enterprises (including Mozilla) take the stance that key management on
the client is beyond the average user. The notable exception is twitter
who are rolling out 2 factor auth based on PKI.
If you're interested in signing stuff with RSA (or other) keys, the web
payments and payswarm guys have done a ton of work on this, including
implementations, which you may be able to reuse ...
>
>
>
>
> ------------------------------------------------------------------------------
> 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/20130809/7a706842/attachment.html>

2023-06-07 15:05:30

- reply

📅 Original date posted:2013-08-04
📝 Original message:A great presentation on advances in crypto
http://www.slideshare.net/astamos/bh-slides
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130804/6ab0d8c5/attachment.html>

2023-06-07 15:05:25

- reply

📅 Original date posted:2013-07-31
📝 Original message:On 31 July 2013 13:33, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami <roy at gnomon.org.uk> wrote:
> >
> > Is it envisaged to be possible/sensible to have a URI that is *only* a
> > payment request? i.e. something like the following (although I'm not
> > sure this is a valid URI):
> >
> > bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe
>
> I think we'll want a bitcoin address in there for a long time for
> backwards compatibility.
>
> If web browser support for arbitrary MIME types is strong enough (I
> haven't tested), then a payment request can be initiated with just an
> anchor tag:
> <a href="https://merchant.com/pay.php?3D2a8628fc2fbe"
> type="application/bitcoin-paymentrequest">
>
Unless I'm mistaken you cant generally set the "Accept" header on a browser
via a standard href ... one of those annoying quirks
>
> Doing it that way saves a http round-trip.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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/20130731/5c2200c4/attachment.html>

2023-06-07 15:04:54

- reply

📅 Original date posted:2013-07-22
📝 Original message:On 22 July 2013 16:44, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Hello,
>
> I should have brought up this suggestion before, as there seems to be
> relevant other work.
>
> I'd like to propose encoding keys data (whatever type) with a birth
> timestamp as:
> * <serialized key>@<unix timestamp in decimal>
>
> The reason for not incorporating this inside the key serialization (for
> example BIP32), is because
> birth timestamps are more generally a property of an address, rather than
> the key it is derived from.
> For one, it is useful for non-extended standard serialized private keys,
> but for P2SH addresses,
> the "private key" is really the actual scriptPubKey, but birth data is
> equally useful for this.
>
> Reason for choosing the '@' character: it's not present in the base58,
> hex, or base64 encodings that
> are typically used for key/script data.
>
> One downside is that this means no checksum-protection for the timestamp,
> but the advantage is
> increased genericity. It's also longer than using a binary encoding, but
> this is an optional
> part anyway, and I think "human typing" is already fairly hard anyway.
>
Is there a BIP for this?
@ is normally used in conjunction with things other than a time stamp ...
You may want to look at RFC 4151
http://www.ietf.org/rfc/rfc4151.txt
They had an idea on adding time stamps to identifiers.
First impression is that the sacrifice in opacity does not seem to justify
the utility.
>
> --
> Pieter
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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/20130722/1a9c17e0/attachment.html>

2023-06-07 15:03:28

- 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:24

- reply

📅 Original date posted:2013-06-15
📝 Original message:On 19 May 2013 15:23, Adam Back <adam at cypherspace.org> wrote:
> Is there a way to experiment with new features - eg committed coins - that
> doesnt involve an altcoin in the conventional sense, and also doesnt impose
> a big testing burden on bitcoin main which is a security and testing risk?
>
> eg lets say some form of merged mine where an alt-coin lets call it
> bitcoin-staging? where the coins are the same coins as on bitcoin, the
> mining power goes to bitcoin main, so some aspect of merged mining, but no
> native mining. and ability to use bitcoins by locking them on bitcoin to
> move them to bitcoin-staging and vice versa (ie exchange them 1:1
> cryptographically, no exchange).
>
> Did anyone figure anything like that out? Seems vaguely doable and
> maybe productive. The only people with coins at risk of defects in a new
> feature, or insufficiently well tested novel feature are people with coins
> on bitcoin-staging.
>
> Yes I know about bitcoin-test this is not it. I mean a real live system,
> with live value, but that is intentionally wanting to avoid forking
> bitcoins
> parameters, nor value, nor mindshare dillution. In this way something
> potentially interesting could move forward faster, and be les risky to the
> main bitcoin network. eg particularly defenses against
>
> It might also be a more real world test test (after bitcoin-test) because
> some parameters are different on test, and some issues may not manifest
> without more real activity.
>
> Then also bitcoin could cherry pick interesting patches and merge them
> after
> extensive real-world validation with real-money at stake (by early
> adopters).
>
Interesting idea. I wonder if ripple could be used to set up a transfer
system between the 'main' and 'staging' systems ...
>
> Adam
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> 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/20130615/ded41a25/attachment.html>

2023-06-07 15:03:20

- reply

📅 Original date posted:2013-06-12
📝 Original message:FYI: some musings on how crypto currencies might be combined with social
good ...
---------- Forwarded message ----------
From: Melvin Carvalho <melvincarvalho at gmail.com>
Date: 12 June 2013 19:39
Subject: The "pay it forward approach" to crypto currencies
To: building-a-distributed-decentralized-internet at googlegroups.com
Crypto currencies are doing quite well, but they have yet to make a
meaningful impact on any economy, nor have they achieved much in the way of
social good, however there is a tangible excitement about ways that it can
modernize the way we live our lives
We live in a world where 10,000 children under the age of five die every
day, which can be prevented by simple, affordable interventions ... why do
we let this happen?
Turning he question on its head, what interventions do crypto currencies
enable us to perform, that could help solve this problem
Well certainly crypto currencies have opened pandora's box in terms of
technology being able to create money, let it float, and let it appreciate
in value ... something that the alchemists of old (whose number include
Aristotle, Newton and Keynes) would have been proud. Well done Satoshi,
now what shall we do with this gift?
The optimal principle should be that we beam new money to the people that
need it most, on a relatively uniform basis. Something of a harder
problem, and one with no perfect solution. But we could make some
approximations ... perhaps.
**
Suppose you were to credit 10,000 new coins to every person on the planet.
Then let it float on the free market (a la bitcoin). Initially worth zero,
the coins would potentially rise in value to become a consensus driven
global dividend. Certainly if it went higher it could do a lot to
alleviate many problems for poorer people.
Unfortunately we dont have a huge database of every person on the planet in
the public domain, so this strategy is problematic. However we roughly do
have good statistics that most people have a mobile phone, so we could beam
coins to every mobile phone. (technically you can do this using the tel:
URI scheme such that you get one phone, one share).
Phones are now banks, and also have the ability to send money via SMS.
The problem with this approach is that it favours people with multiple
phones, who are probably correlated to relatively wealthy people. Not
great, but it's a start.
How about we then do it country by country and beam coins to the poorest
countries, say in proportion to GNP per capita. Perhaps better.
Again, it's possible to systematically game the system, to an extent. So
one way to reduce the risk would be to allocate coins on a lottery basis,
where a random number generator selects 'lucky' winners. The net effect
will be generally positive, while preventing major systemic risk.
Little by little, we can bring people out of poverty using crypto coins and
make a better world.
Now, I know what you're thinking. Money for nothing, that makes no sense.
Why would these coins ever be worth anything.
There is where the "pay it forward" concept comes in. All coin recipients
are encouraged to "pay it forward" ... do good for the sake of good, and
allow that karma to flow back to you. Eventually this can take the form of
rebuying the coins that saved your life when you were young, and enabled
you to become a successful businessman.
As the value, liquidity, trust, and importantly, social good of the system
build. So it becomes easier for people to maintain societies, for
economies to thrive, and for governments to balance their budgets.
It becomes an ever increasing virtuous circle, that can transform the
planet.
I've left out a few gaps and technical details, but I'm sure it's possible
to join the dots and incrementally move towards an optimal solution. I
think bitcoin and the internet have paved the way for "pay it forward"
crypto currencies.
And hopefully it can one day become "an idea worth spending". :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130612/b5b76c0c/attachment.html>

2023-06-07 15:03:19

- reply

📅 Original date posted:2013-06-22
📝 Original message:On 11 June 2013 17:29, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
> > For the sake of argument let's say that opaque means that you can tell
> > nothing about the address by examining the characters.
>
> This is true or false based on CONTEXT.
>
> Obviously, an implementation of transaction handling (eg, wallets) needs
> to be
> able to translate addresses to and from what they represent.
>
> On the other hand, things like URI handlers do not (and should not) try to
> interpret the address as anything other than an arbitrary word (\w+).
>
Luke, if you think that the sole purpose of a URI scheme is to be used as a
URI handler, I think you've not fully understood the concept. URIs are the
global variable of the internet, and as such the need to play nicely with
all other URI schemes on the net. They need to be able to be linked to, to
be defined and documented. This is important for bitcoin to get right
because bitcoin: needs to treated in a special way on the internet, I just
saw today that it was treated by some software as a relative URL, which is
going to break a ton of stuff.
>
> > My understanding was that they are NOT opaque, and that if that has
> > changed, it will invalidate much at least some wiki page, for examples at
> > least some of the following would now be false:
>
> The wiki goes into much detail on how addresses work, which is not the
> concern
> of most software in the Bitcoin ecosystem, but may be of interest to humans
> and developers working on the one component that operates the "black box"
> that
> addresses are.
>
> > --------
> > <snip>
> > --------
>
> These aren't FALSE, they are "true at the moment, but subject to revision
> by
> newer standards".
>
> > I also here that there is a LIKELY change from the base58 encoding ...
> when
> > was this established?
>
> I stated (on IRC) that it was likely Bitcoin would change from the base58
> encoding for addresses ... at some unspecified time in the future, to some
> unspecified new encoding that addressed known limitations of base58. What
> those changes will be, or when, are not all established at this time. The
> only
> currently-planned change to addresses (very loosely defined) is inclusion
> of
> the Payment Protocol URIs. But the point is that software developers
> shouldn't
> assume that addresses will remain base58 forever.
>
I am opposed to address changes in general, until he wider implications are
fully understood.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130622/d05ef409/attachment.html>

2023-06-07 15:03:18

- reply

📅 Original date posted:2013-06-15
📝 Original message:On 11 June 2013 17:29, Luke-Jr <luke at dashjr.org> wrote:
> On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
> > For the sake of argument let's say that opaque means that you can tell
> > nothing about the address by examining the characters.
>
> This is true or false based on CONTEXT.
>
> Obviously, an implementation of transaction handling (eg, wallets) needs
> to be
> able to translate addresses to and from what they represent.
>
> On the other hand, things like URI handlers do not (and should not) try to
> interpret the address as anything other than an arbitrary word (\w+).
>
I think this statement may need to be justified.
>
> > My understanding was that they are NOT opaque, and that if that has
> > changed, it will invalidate much at least some wiki page, for examples at
> > least some of the following would now be false:
>
> The wiki goes into much detail on how addresses work, which is not the
> concern
> of most software in the Bitcoin ecosystem, but may be of interest to humans
> and developers working on the one component that operates the "black box"
> that
> addresses are.
>
> > --------
> > <snip>
> > --------
>
> These aren't FALSE, they are "true at the moment, but subject to revision
> by
> newer standards".
>
Got it.
>
> > I also here that there is a LIKELY change from the base58 encoding ...
> when
> > was this established?
>
> I stated (on IRC) that it was likely Bitcoin would change from the base58
> encoding for addresses ... at some unspecified time in the future, to some
> unspecified new encoding that addressed known limitations of base58. What
> those changes will be, or when, are not all established at this time. The
> only
> currently-planned change to addresses (very loosely defined) is inclusion
> of
> the Payment Protocol URIs. But the point is that software developers
> shouldn't
> assume that addresses will remain base58 forever.
>
Does this mean that people should not be investing in "vanity addresses"?
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130615/7197e065/attachment.html>

2023-06-07 15:03:16

- reply

📅 Original date posted:2013-06-10
📝 Original message:On 10 June 2013 23:09, Peter Todd <pete at petertodd.org> wrote:
> So here's the parts that need to be done for step #1:
>
>
> # Protocol Work
>
> Basic idea is the miner makes two connections, their pool, and a local
> bitcoind.
>
> They always (usually?) work on the subset of transactions common to both
> the pool's getblocktemplate and their local one. When they find a share
> if it doesn't meet difficulty they just hand it to the pool. Currently
> that is done by handing the whole block over, correct? I know the BIP
> says otherwise, but we should optimize this to just hand over tx hashes
> where possible.
>
> If the share does meet difficulty, hand it to both the pool and the
> local bitcoind. Should hand it to the pool first though, because the
> pool likely has the fastest block propagation, then hand it to local
> bitcoind. An optimized version may want to have some record of measured
> bandwidth - this applies Bitcoin in general too, although also has other
> issues.
>
>
> ## Reducing bandwidth
>
> How about for normal shares we just pass the block header, and have the
> pool randomly pick a subset of transactions to audit? Any fraud cancels
> the users shares. This will work best in conjunction with a UTXO proof
> tree to prove fees, or by just picking whole shares randomly to audit.
>
> We'll need persistent share storage so if your connection disconnects
> you can provide the pool with the full share later though.
>
> Incedentally, note how the miner can do the reverse: pick random block
> headers and challenge the pool to prove that they correspond to a valid
> block. With some modifications Stratum can support this approach.
>
>
> ## Delibrate orphaning of slow to propagate blocks
>
> Block headers can be flooded-filled much faster than blocks themselves.
> They are also small enough to fit into a UDP packet. Nodes should pass
> headers around separately via UDP, optinally with some tiny number of
> transactions. When we see a valid block header whose contents we do not
> know about a miner should switch to mining empty or near empty blocks in
> solo mode that would orphan the still propagating block. Doing this is
> safe, we'll never build on an invalid block, economically rational while
> the inflation subsidy is still high, and helps reduce (although not
> eliminate!) the advantage a large miner with high-bandwidth connections
> has over those who don't.
>
> Of course, the other option is to build a block extending the one you
> don't know about, which is even more rational, but doing poses major
> risks to Bitcoin...
>
> This functionality can be implemented later - it's not strictly part of
> pooled-solo mode.
>
>
> # Pool work
>
> So does eliopool already accept arbitrary shares like this and do the
> correct accounting already? (IE adjust share amount based on fees?) What
> happens when the pool doesn't get the share directly, but does see the
> new block?
>
> + possible protocol extensions
>
>
> # Miner work
>
> Basically we need code to merge the two block templates together to find
> commonality. I guess you probably want to implement this in bfgminer
> first, so add the code to libblkmaker first, then maybe python-blkmaker.
>
> We also want an automatic fallback to local solo mining if the pool
> can't be contacted.
>
> + possible protocol extensions
>
Sounds very promising. Suspect it will need a fair amount of testing ...
>
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189
>
>
> ------------------------------------------------------------------------------
> 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/20130610/78f5d4ac/attachment.html>

2023-06-07 15:03:16

- reply

📅 Original date posted:2013-06-11
📝 Original message:There was some confusion on IRC as to whether bitcoin addresses are opaque
or not.
https://en.bitcoin.it/wiki/Address
For the sake of argument let's say that opaque means that you can tell
nothing about the address by examining the characters.
My understanding was that they are NOT opaque, and that if that has
changed, it will invalidate much at least some wiki page, for examples at
least some of the following would now be false:
--------
"A Bitcoin address, or simply address, is an identifier of 27-34
alphanumeric characters" -- FALSE
"with the number 1 or 3" -- FALSE
"you can send bitcoins to a person by sending bitcoins to one of their
addresses" -- FALSE
"Addresses are created simply by generating random numbers and then
performing mathematical operations to derive matching pairs of "public" and
"private" keys" -- FALSE
"The probability that a mistyped address is accepted as being valid is 1 in
232, that is, approximately 1 in 4.29 billion" -- FALSE
"If you would like to validate a Bitcoin address in an application, it is
advisable to use a method from this thread rather than to just check for
string length, allowed characters, or that the address starts with a 1 or
3." -- FALSE
"For most properly-generated Bitcoin addresses, there is at least one
secret number known as a private key" -- FALSE
"They consist of random digits and uppercase and lowercase letters, with
the exception that the uppercase letter "O", uppercase letter "I",
lowercase letter "l", and the number "0" are never used to prevent visual
ambiguity" -- FALSE
"Some Bitcoin addresses can be shorter than 34 characters (as few as 27)"
-- FALSE
"Several of the characters inside a Bitcoin address are used as a checksum
so that typographical errors can be automatically found and rejected" --
FALSE
"The checksum also allows Bitcoin software to confirm that a 33-character
(or shorter) address is in fact valid and isn't simply an address with a
missing character" -- FALSE
--------
I also here that there is a LIKELY change from the base58 encoding ... when
was this established?
There's either been some bit changes to the fundamentals of bitcoin here or
there's been some misunderstandings. It would be good to clear things up
as to what exactly an address is now beleived to be, and reflect that in
the wiki.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130611/8d2e4750/attachment.html>

2023-06-07 15:03:11

- reply

📅 Original date posted:2013-06-22
📝 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.
>
Thinking about this a little more, I guess it does not hurt to build some
kind of voting system into the clients. But I think it's more useful for
straw polls. For example a bug fix 100% of people should agree on. A
protocol optimization perhaps 80% would agree on. A protocol change that
redistributes wealth or incentives perhaps only 60% will agree on.
At this point in time it's far too easy to deliver contentious changes into
the hands of the general population. I think that fortunately we're
blessed with a very strong dev team, but the fundamental philosophy of
bitcoin is to not put too much trust in single point, but rather, to
distribute and diversify trust to the edges.
> -----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-----
>
>
> ------------------------------------------------------------------------------
> 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/20130622/230318e0/attachment.html>

2023-06-07 15:03:06

- 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

- 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

- 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

- 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:52

- reply

📅 Original date posted:2013-06-06
📝 Original message:On 6 June 2013 02:19, Peter Vessenes <peter at coinlab.com> wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking large
> corporations taking money from consumers over fraudulent reversals.
> Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will sign
> at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period when
> you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted
> escrow service, and is vulnerable to griefing, but I thought I'd see if
> some of the brighter minds than me can come up with a layer-on approach
> here.
>
> When I think about it, I can imagine that I would put a good number of my
> coins in a one day reversible system, because I would have warning if
> someone wanted to try and spend them, and could do something about it. I'm
> not sure if it gets me anything over a standard escrow arrangement, though.
>
Also see satoshi's comments on this, though it may be restating what others
have said:
https://bitcointalk.org/index.php?topic=750.0
"Here's an outline of the kind of escrow transaction that's possible in
software. This is not implemented and I probably won't have time to
implement it soon, but just to let you know what's possible.
The basic escrow: The buyer commits a payment to escrow. The seller
receives a transaction with the money in escrow, but he can't spend it
until the buyer unlocks it. The buyer can release the payment at any time
after that, which could be never. This does not allow the buyer to take the
money back, but it does give him the option to burn the money out of spite
by never releasing it. The seller has the option to release the money back
to the buyer.
While this system does not guarantee the parties against loss, it takes the
profit out of cheating.
If the seller doesn't send the goods, he doesn't get paid. The buyer would
still be out the money, but at least the seller has no monetary motivation
to stiff him.
The buyer can't benefit by failing to pay. He can't get the escrow money
back. He can't fail to pay due to lack of funds. The seller can see that
the funds are committed to his key and can't be sent to anyone else.
Now, an economist would say that a fraudulent seller could start
negotiating, such as "release the money and I'll give you half of it back",
but at that point, there would be so little trust and so much spite that
negotiation is unlikely. Why on earth would the fraudster keep his word and
send you half if he's already breaking his word to steal it? I think for
modest amounts, almost everyone would refuse on principle alone."
>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> 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/20130607/c8a04aa5/attachment.html>

2023-06-07 15:02:49

- reply

📅 Original date posted:2013-06-05
📝 Original message:On 6 June 2013 02:19, Peter Vessenes <peter at coinlab.com> wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>
It's great that this article quotes the first page of Sasoshi's white
paper. There are some other text that they missed, though, which I think
may be relevant.
[[
Completely non-reversible transactions are not really possible, since
financial institutions cannot
avoid mediating disputes. The cost of mediation increases transaction
costs, limiting the
minimum practical transaction size and cutting off the possibility for
small casual transactions,
and there is a broader cost in the loss of ability to make non-reversible
payments for non-
reversible services. With the possibility of reversal, the need for trust
spreads. Merchants must
be wary of their customers, hassling them for more information than they
would otherwise need.
A certain percentage of fraud is accepted as unavoidable. These costs and
payment uncertainties
can be avoided in person by using physical currency, but no mechanism
exists to make payments
over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic proof
instead of trust,
allowing any two willing parties to transact directly with each other
without the need for a trusted
third party. Transactions that are computationally impractical to reverse
would protect sellers
from fraud, and routine escrow mechanisms could easily be implemented to
protect buyers.
]]
>
> I will hold my thoughts about the net social good of rent-seeking large
> corporations taking money from consumers over fraudulent reversals.
> Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will sign
> at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period when
> you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a trusted
> escrow service, and is vulnerable to griefing, but I thought I'd see if
> some of the brighter minds than me can come up with a layer-on approach
> here.
>
> When I think about it, I can imagine that I would put a good number of my
> coins in a one day reversible system, because I would have warning if
> someone wanted to try and spend them, and could do something about it. I'm
> not sure if it gets me anything over a standard escrow arrangement, though.
>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> 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/592bb5b3/attachment.html>

2023-06-07 15:02:47

- reply

📅 Original date posted:2013-06-05
📝 Original message:FYI: I think this may be a possible blue print for a web version of
bitcoin+ripple combined.
---------- Forwarded message ----------
From: Melvin Carvalho <melvincarvalho at gmail.com>
Date: 5 June 2013 18:50
Subject: Creating a Currency for the (Read / Write) Web
To: public-rww <public-rww at w3.org>, Nathan Rixham <nrixham at gmail.com>, Web
Payments <public-webpayments at w3.org>
I've been thinking for a while about how to create a currency for the read
write web. And I thought I'd share some preliminary ideas. Essentially
this is bitcoin+ripple translated to the Web.
*Introduction
*
For those not familiar with the bitcoin concept it's essentially a
distributed ledger where each subject is a primary key in the ledger and
can hold 0 or more coins. Coins are transferred using a signed and
timestamped PKI transaction log from one address to another, in a
distributed data base.
*Addresses
*
I think using a portable URI for addresses is the thing that makes most
sense. So possibilities for this may be a URN, or schemes such as di:
(digest) or ni: (named information). Anyone should be able to generate an
address, and they should be wide ranging to improve liquidity.
*Balances
*
Balances can be calculated by summing all inputs to that address. You can
additionally keep a state of balances using the payswarm vocab, or perhaps,
goodRelations
*Transactions
*
I think a distributed data base could be maintained using read / write web
technologies, such as HTTP POST / PATCH or SPARQL Update. The signatures
could be added using the WebKeys spec.
*Distributed Database
*
There are challenges associated with maintaining a distributed database. I
suggest we start small and whoever opts in can become part of the
verification process. There are two recent methods for mitigating race
conditions an important one of which is called "double spend". One is
proof of work, the other is consensus based on a unique node list. I would
suggest using both techniques. I'd like it to be possible to use both HTTP
(with self signed certificates), HTTP, and (secure) websockets too as the
transport layer.
*Coin Creation
*
This tends to be the most contentious point, with people tending not to
like the "premine" concept where you allocate coins to yourself. However
companies like opencoin have successfully rolled out multi million or even
billion dollar premine schemes. I would suggest coin creation in line with
bitcoin, where they are created proportionally to those maintaining the
integrity of rhe shared database.
*Spam Protection
*
Given the nature of the system, it may be easy to spam the network with
micro transactions. As such there should be a transaction fee where those
that pay the highest fee are prioritized.
*Trust and Reputation
*
I think it would also help to have a trust and reputation system added to
the process, such that honest nodes benefit from acting honestly, and nodes
which are dishonest or not up to date are considered less dubious. The
nature of the function should be that it's exponentially harder to gain
trust after you have a certain score. Similar to chess ELO ratings.
*Linked Data and Exensibility
*
I think there should be a deep integration with web principles and linked
data to promote an app eco system and allow unexpected reuse. Also it
should allow extensions such as the ripple protocol's trust lines, IOUs and
distributed markets, which are not initially scoped out. Reusing existing
concepts such as the bitcon blockchain (e.g. so-called coloured coins),
ripple ledger, opentransactions, payswarm and web credits should all be
doable.
Just some food for thought. Criticisms welcome. Please let me know if
you're interested in running a node, and maybe we an get a reference
implementation going, as proof of concept.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/348483b9/attachment.html>

2023-06-07 15:02:46

- reply

📅 Original date posted:2013-06-06
📝 Original message:On 6 June 2013 23:48, Luke-Jr <luke at dashjr.org> wrote:
> On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
> > > This doesn't work like you might think: first of all, the fees today
> are
> > > greatly subsidized - the actual cost to store data in the blockchain is
> > > much higher than most storage solutions. Secondly, only the miner
> receives
> > > the fees, not the majority of nodes which have to bear the burden of
> the
> > > data. That is, the fee system is setup as an antispam/deterrant, not as
> > > payment for
> > > storage.
> >
> > There's a difference between storing the content itself, and storing
> just a
> > hash to content (which however is not spendable payment). I undertand why
> > content itself doesn't belong. But it goes too far to say that only
> > payments should be allowed.
>
> Because payments are the only thing everyone using Bitcoin has agreed to
> use
> the blockchain for. Furthermore, there is no *reason* to store
> non-payments in
> the blockchain. If there was in fact such a use case, things might be
> arguable
> - but there isn't any I'm aware of.
>
Two quotes satoshi:
"Piling every proof-of-work quorum system in the world into one dataset
doesn't scale."
and
"I like Hal Finney's idea for user-friendly timestamping. Convert the hash
of a file to a bitcoin address and send 0.01 to it"
This leads me to believe, that while bitcoin should not be over used as a
time stamp server, there could be a balance reached for casual time stamp
recording as part of satoshi's concept.
What we call "spam" is to a degree subjective, and I think not always
obvious, tho in some cases it clearly is.
> > If the fees are not enough, fix the fee structure, don't stop incredibly
> > innovative and promising uses of the distributed timestamping database.
> > That is definitely throwing the baby out with the bathwater. If the issue
> > is size, then address that, rather than the content itself.
>
> The issue is using other peoples' resources for something they did not
> agree
> to use it for. The fees aren't merely "not enough", they were never
> *intended*
> to be "cost of storage". They are "cost of security" and "prevent
> spamming".
>
> > Discriminating based on transaction content violates neutrality of the
> > protocol and in my mind removes a very very large possibility of future
> > innovation. If bitcoin is a *platform* and not just a payment system,
> then
> > it needs to be neutral to content, like TCP/IP so that other protocols
> can
> > be layered. Solve the size problem itself, without picking and chosing
> > which uses of bitcoin are good and which are "bad" or "spam". I think it
> > risks killing a tremendous amount of innovation just as it is starting.
>
> The concepts behind Bitcoin are applicable to future innovation, but this
> can
> all be accomplished without spamming Bitcoin itself.
>
> > > Not the same thing at all; nobody is forced to store/relay
> > > video/voice/images without reimbursement. On the other hand, any full
> > > Bitcoin node is required to at least download the entire blockchain
> once.
> > > And the network as a whole suffers if nodes decide to start not-storing
> > > parts of the blockchain they don't want to deal with.
> > >
> > > So don't store content, but allow hashes of content.
> >
> > Again, I think it is extreme and extremely restrictive to say that ONLY
> > payments are allowed.
>
> Non-payments are quite possible without the Bitcoin blockchain itself. If
> you're worried that not enough people will store the
> alternative-non-payment
> data, then you are essentially saying that voluntary participation is not
> enough and that forced storage is your solution. I don't think this is what
> you intend...
>
> > > This is how merged mining solves the problem. A single extra hash in
> the
> > > coinbase can link the bitcoin blockchain up with unlimited other data.
> >
> > Can you explain this part or refer me to some docs? What do you mean by
> > "coinbase", I assume not the company.
>
> The Bitcoin blockchain protocol has 95 bytes per block reserved for miners
> to
> put extra data. Currently, this is used for extranonces, political or other
> short messages (such as in the Genesis block), miner "signatures", and
> also,
> as I mentioned, merged mining. Merged mining works by tying a non-
> transactional merkle tree to the blockchain. The block coinbase stores the
> hash of the top of this merkle tree, so any data within the merkle tree can
> prove it is associated to the block. The merged mining merkle tree then
> stores
> hashes of multiple other data sets: for example, a Namecoin block can be
> referenced in a merged mining merkle tree, to use the Bitcoin block's
> proof-
> of-work for itself (so, miners can mine both Bitcoin and Namecoin using the
> same hashing effort). You could also add other non-transactional blocks to
> the
> merged mining merkle tree, for generic timestamping or really anything at
> all.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130607/79f171a4/attachment.html>

2023-06-07 15:02:43

- 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

- 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:27

- reply

📅 Original date posted:2013-05-25
📝 Original message:On 25 May 2013 10:53, Luke-Jr <luke at dashjr.org> wrote:
> On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> > It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> > out separately
>
> Bitcoin is a consensus system. You can't run clients with different rules
> on
> the same blockchain/network - it just won't work! Maybe we're now talking
> about mere client default policies? In which case, you should be able to
> configure previous behaviour...
>
[[ Not wishing to stray too far off topic ]]
I think you are perhaps underestimating the effect of 'mere' default
policies.
It would be nice to think that every node was a free thinking individual
that is motivated to vote with their feet, but in practice most people dont
have time.
There is research showing that 80% of users tend to accept defaults.
Rule changes and changing defaults would seem to be things worth weighing.
Bug fixes hopefully should be fairly unanimous. Of course a grey area
exists in between.
>
> If you want just bug fixes and rule changes, without policy default
> changes,
> new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised
> these are short-term solutions and won't be maintained forever - so you
> really
> should try to get the behaviour you want from the current release. If you
> can't for some reason, please do report a bug explaining what it is the
> older
> version was capable of that the new one isn't!
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130525/ddcd58cc/attachment.html>

2023-06-07 15:02:26

- 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 15:02:12

- reply

📅 Original date posted:2013-05-22
📝 Original message:On 22 May 2013 16:07, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
> <melvincarvalho at gmail.com> wrote:
> > Some out of band algo/hash could work so long as there was a one to one
> > relationship between the described object and the UUID. In this case the
> > gensis block may not uniquely identify a coin.
>
> What does this mean? It seems extremely unlikely that two different
> genesis blocks will have the same hash.
>
Two coin ecosystems could have the same genesis block
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130522/811027e3/attachment.html>

2023-06-07 15:02:11

- reply

📅 Original date posted:2013-05-22
📝 Original message:On 21 May 2013 01:59, Mark Friedenbach <mark at monetize.io> wrote:
> At the developer round-table it was asked if the payment protocol would
> alt-chains, and Gavin noted that it has a UTF-8 encoded string
> identifying the network ("main" or "test"). As someone with two
> proposals in the works which also require chain/coin identification (one
> for merged mining, one for colored coins), I am opinionated on this. I
> believe that we need a standard mechanism for identifying chains, and
> one which avoids the trap of maintaining a standard registry of
> string-to-chain mappings.
>
> Any chain can be uniquely identified by its genesis block, 122 random
> bits is more than sufficient for uniquely tagging chains/colored assets,
> and the low-order 16-bytes of the block's hash are effectively random.
> With these facts in mind, I propose that we identify chains by UUID.
>
> So as to remain reasonably compliant with RFC 4122, I recommend that we
> use Version 4 (random) UUIDs, with the random bits extracted from the
> double-SHA256 hash of the genesis block of the chain. (For colored
> coins, the colored coin definition transaction would be used instead,
> but I will address that in a separate proposal and will say just one
> thing about it: adopting this method for identifying chains/coins will
> greatly assist in adopting the payment protocol to colored coins.)
>
> The following Python code illustrates how to construct the chain
> identifier from the serialized genesis block:
>
> from hashlib import sha256
> from uuid import UUID
> def chain_uuid(serialized_genesis_block):
> h = sha256(serialized_genesis_block).digest()
> h = sha256(h).digest()
> h = h[:16]
> h = ''.join([
> h[:6],
> chr(0x40 | ord(h[6]) & 0x0f),
> h[7],
> chr(0x80 | ord(h[8]) & 0x3f),
> h[9:]
> ])
> return UUID(bytes=h)
>
> And some example chain identifiers:
>
> mainnet: UUID('6fe28c0a-b6f1-4372-81a6-a246ae63f74f')
> testnet3: UUID('43497fd7-f826-4571-88f4-a30fd9cec3ae')
> namecoin: UUID('70c7a9f0-a2fb-4d48-a635-a70d5b157c80')
>
> As for encoding the chain identifier, the simplest method is to give
> "network" the "bytes" type, but defining a "UUID" message type is also
> possible. In either case bitcoin mainnet would be the default, so the
> extra 12 bytes (vs: "main" or "test") would only be an issue for
> alt-chains or colored coins.
>
This is essentially name spacing. As registries grow namespaces become
more important. In bitcoin's quest for decentrality there's also the
question of who maintains the registry.
Some out of band algo/hash could work so long as there was a one to one
relationship between the described object and the UUID. In this case the
gensis block may not uniquely identify a coin.
The normal way to namespace a registry on the internet is to allow it to be
a URI. In this case an http style uri has the added bonus side effect that
it can be dereferencable and both human and machine readable. So yes
something like org.bitcoin.* is good, just simply growing things to http
style uris is cleaner, imho
>
> Kind regards,
> Mark Friedenbach
>
>
> ------------------------------------------------------------------------------
> 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/20130522/d01951b4/attachment.html>

2023-06-07 15:02:01

- reply

📅 Original date posted:2013-05-15
📝 Original message:On 15 May 2013 13:38, Peter Todd <pete at petertodd.org> wrote:
> Now that I have the replace-by-fee reward, I might as well spread the
> wealth a bit.
>
>
> So for all this discussion about replace-by-fee and the supposed
> security of zero-conf transactions, no-one seems to think much about how
> in practice very few vendors have a setup to detect if conflicting
> transactions were broadcast on the network simultaneously - after all if
> that is the case which transaction gets mined is up to chance, so much
> of the time you'll get away with a double spend. We don't yet have a
> mechanism to propagate double-spend warnings, and funny enough, in the
> case of a single txin transaction the double-spend warning is also
> enough information to allow miners to implement replace-by-fee.
>
>
> So I'm offering 2BTC for anyone who comes up with a nice and easy to use
> command line tool that lets you automagically create one version of the
> transaction sending the coins to the desired recipient, and another
> version sending all the coins back to you, both with the same
> transaction inputs. In addition to creating the two versions, you need
> to find a way to broadcast them both simultaneously to different nodes
> on the network. One clever approach might be to use blockchain.info's
> raw transaction POST API, and your local Bitcoin node.
>
> If you happen to be at the conference, a cool demo would be to
> demonstrate the attack against my Android wallet. I'll buy Bitcoins off
> of you at Mt. Gox rates + %10, and you can see if you can rip me off.
> Yes, you can keep the loot. :) This should be videotaped so we can put
> an educational video on youtube after.
>
Isnt it potentially inviting trouble by encouraging people to insert double
spends into the block chain?
Sure, zero conf isnt 100% safe, we all know that.
But neither is the postal service. Doesnt mean we should be going around
promoting the creation of tools to go into people's maiilboxes and open
their letters!
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000bafd0a55f013e058cc2a672ee0c66b9265a02390d80e4748f5
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> 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/20130515/c2398578/attachment.html>

2023-06-07 15:01:58

- reply

📅 Original date posted:2013-05-14
📝 Original message:On 14 May 2013 20:41, Peter Todd <pete at petertodd.org> wrote:
> report: https://bitcointalk.org/index.php?topic=205349.0
>
> Every talk will be widely witnessed and videotaped so we can get some
> reasonably good security by simply putting out PGP fingerprints in our
> slides. Yeah, some fancy attacker could change the videos after the
> fact, but the talks themselves will have wide audiences and a lot of
> opportunities for fraud to be discovered. That means it'd also be
> reasonable for people to sign those keys too if you are present and are
> convinced you aren't looking at some impostor. (of course, presenters,
> check that your PGP fingerprints are correct...)
>
>
> Remember that PGP depends on the web-of-trust. No single measure in a
> web-of-trust is needs to be absolutely perfect; it's the sum of the
> verifications that matter. I don't think it matters much if you have,
> say, seen Jeff Garzik's drivers license as much as it matters that you
> have seen him in a public place with dozens of witnesses that would
> recognize him and call out any attempt at fraud.
>
> Secondly remember that many of us are working on software where an
> attacker can steal from huge numbers of users at once if they manage to
> sneak some wallet stealing code in. We need better code signing
> practices, but they don't help without some way of being sure the keys
> signing the code are valid. SSL and certificate authorities have
> advantages, and so does the PGP WoT, so use both.
>
>
> FWIW I take this stuff pretty seriously myself. I generated my key
> securely in the first place, I use a hardware smartcard to store my PGP
> key, and I keep the master signing key - the key with the ability to
> sign other keys - separate from my day-to-day signing subkeys. I also
> PGP sign emails regularly, which means anyone can get a decent idea of
> if they have the right key by looking at bitcoin-development mailing
> list archives and checking the signatures. A truly dedicated attacker
> could probably sign something without my knowledge, but I've certainly
> raised the bar.
>
Just out of curiosity, could PGP keyservers suffer from a similar 51%
attack as the bitcoin network?
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000016be577c0f0ce4c04a05fdbfc8e0b6f69053659f32aeea3a518
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> 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/20130514/17d09b72/attachment.html>

2023-06-07 15:01:28

- 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 15:01:27

- 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

- reply

2023-06-07 14:56:38

- reply

2023-06-07 11:48:41

- reply

📅 Original date posted:2013-04-27
📝 Original message:On 24 April 2013 16:46, Craig B Agricola <craig at theagricolas.org> wrote:
> Maybe I'm missing something crucial, but what benefit does this dance give
> over
> the slightly more obvious mechanism of simply:
> 1) Alice generates a new address with her bitcoin client and sends the BTC
> to
> this new address
> 2) Alice exports the private key for that address (there is a well
> supported
> format for that)
> 3) Alice writes a nice email to Bob, including that exported private key
> 4) Alice encrypts the email with Bob's public key using GPG and sends it
> to him
> by email
> 5) Bob decrypts the email
> 6) Bob imports the private key into his wallet
>
Yes this works too.
However is it dependent on the bitcoin client address generation algorithm?
I think what I'm trying to describe is something more akin to the way a
shared secret is generated by TLS.
Agree, that the wallet is also shared, ive not yet worked out a way to
'blind' one side of the wallet, but nor have a proved it's impossible, so
still working onthat :)
>
> There's no need for sending a whole wallet; just the one key is needed.
> Every
> bit of infrastructure needed above already exists. And of course, the
> above
> has the same issue as your proposal; this is a way for two trusting
> parties to
> send BTC without using the Bitcoin network, but it's not a payment
> mechanism.
> They now share control of an address; whoever spends that BTC first wins,
> so
> until Bob uses the Bitcoin network to spend that BTC to another address
> that
> only he controls, it's still in joint custody. And if ensuring that he has
> control of the BTC is the last (implicit) step in the procedure above, as
> well
> as yours, then they might as well have simply used the Bitcoin network to
> do
> the transfer in the first place.
>
> Did I miss the point entirely?
>
Perhaps I've not described the problem statement as clearly as I could,
I'll work on it. Essentially it's an automated way to bootstrap the RSA
key community together with bitcoin. e.g. 99% of GPG users probably dont
have a bitcion wallet or address or client. I think maybe a user story
will help.
>
> -Craig
>
> PS. Re-reading, I realize that the above might come off sounding snarky or
> dismissive; it's not intended that way. I'm wondering if I'm missing
> the
> big picture.
>
Not snarky at all! Appreciate the feedback...
>
> On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote:
> > So there's a slight world divide in digital payments with bitcoin using
> > ECDSA and GPG, payswarm / webid etc using largely RSA
> >
> > Here's how to bring the two worlds together and enable bitcoins be sent
> > over webid or payswarm
> >
> >
> > Problem: Alice and Bob have RSA key pairs, but no public bitcoin
> > addresses. Alice wants to send 1 BTC to Bob.
> >
> > 1. Alice takes Bob's WebID and encrpyts it with her private key (to
> create
> > entropy) ...
> >
> > 2. Alice uses that message as the seed to produce btc address (as per
> > http://brainwallet.org ) with ECDSA key pair
> >
> > 3. Alice sends coins to this address
> >
> > 4. Alice and then encrypts the seed again with Bob's public key
> >
> > 5. Bob decrypts the seed using his private key
> >
> > 6. Bob can now use the seed to recreate the wallet and spend the coins
> >
> > Unless I've made an error, I believe this unites the web paradigm and
> > crypto currency paradigm into one potentially giant eco system ...
>
> >
> ------------------------------------------------------------------------------
> > 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_apr
>
> > _______________________________________________
> > 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/20130427/cf515b60/attachment.html>

2023-06-07 11:48:35

- reply

📅 Original date posted:2013-04-24
📝 Original message:So there's a slight world divide in digital payments with bitcoin using
ECDSA and GPG, payswarm / webid etc using largely RSA
Here's how to bring the two worlds together and enable bitcoins be sent
over webid or payswarm
Problem: Alice and Bob have RSA key pairs, but no public bitcoin
addresses. Alice wants to send 1 BTC to Bob.
1. Alice takes Bob's WebID and encrpyts it with her private key (to create
entropy) ...
2. Alice uses that message as the seed to produce btc address (as per
http://brainwallet.org ) with ECDSA key pair
3. Alice sends coins to this address
4. Alice and then encrypts the seed again with Bob's public key
5. Bob decrypts the seed using his private key
6. Bob can now use the seed to recreate the wallet and spend the coins
Unless I've made an error, I believe this unites the web paradigm and
crypto currency paradigm into one potentially giant eco system ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130424/d07c27b0/attachment.html>

2023-06-07 11:48:29

- reply

📅 Original date posted:2013-04-24
📝 Original message:On 24 April 2013 09:42, Mike Hearn <mike at plan99.net> wrote:
> HTML5 allows web apps to register themselves for handling URI schemes,
> such as the bitcoin: URI that is already in use and being extended as part
> of the payment protocol.
>
> The bad news is that for security reasons there is a whitelist of
> acceptable schemes in the spec:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
>
> The good news is that yesterday I talked to Hixie about it and he added
> bitcoin to the whitelist:
>
> http://html5.org/tools/web-apps-tracker?from=7849&to=7850
>
> I'm currently finding out what the process is for browser makers to notice
> the change (perhaps they watch the spec commit history and nothing needs to
> be done), but within a few months most users should have browsers that can
> accept bitcoin as a web-app handleable protocol scheme. I suppose IE10
> users may be the laggards, but I guess we can live with that for now.
>
This is great news for bitcon, and the IANA application will be improved if
there is evidence of it being used
>
> Ian pointed out some errors in the BIP21 spec. What's the process for
> amending the BIP? Do we need to create a new one and mark the old one as
> replaced, or can we just fix it in place given the relatively exotic nature
> of most of the issues? Here's his feedback:
>
>
> - BNF doesn't say what it's character set is (presumably it's Unicode)
>
> - "bitcoinparams" production doesn't define the separator, so in theory
> the syntax is ...?label=foomessage=fooother=foo (rather than
> ...?label=foo&message=foo etc)
>
> - the syntax allows ?amount=FOO&amount=1.1 as far as I can tell, since
> "otherparam" matches any name followed by any value, including "amount"
> followed by a bogus value.
>
> - "pchar" is referenced without definition.
>
> - the "simpler" syntax is just wrong (it would result in
> bitcoin:address?amount=1?label=FOO rather
> than bitcoin:address?amount=1&label=FOO)
>
> BTW the IETF URL specs are being obsoleted by http://url.spec.whatwg.org/,
> at least for Web purposes. In that case matters.
>
Not 100% sure how accurate this is, tho it may be the world view of some
folks in WHATWG. WHATWG is not a major standards body tho. Work on
improving the URL spec is always welcome, as it is the value proposition of
the Web.
>
>
>
> ------------------------------------------------------------------------------
> 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_apr
> _______________________________________________
> 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/20130424/46ad6cd9/attachment.html>

2023-06-07 11:48:05

- reply

📅 Original date posted:2013-04-16
📝 Original message:FYI: this is worth a read for anyone interested in the payment ecosystem on
the WWW ... it's about 5 years of work, and there's a even hope to
integrate bitccoin too ...
https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/
I've cc'd Manu in case anyone here has any questions!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130416/0dbf08aa/attachment.html>

2023-06-07 11:43:32

- reply

📅 Original date posted:2013-04-05
📝 Original message:On 5 April 2013 11:48, Mike Hearn <mike at plan99.net> wrote:
> 51% isn't a magic number - it's possible to do double spends against
> confirmed transactions before that. If Michael wanted to do so, with the
> current setup he could, and that's obviously rather different to how
> Satoshi envisioned mining working.
>
Thanks for pointing this out. I guess 51% is mainly of psychological
significance.
>
> However, you're somewhat right in the sense that it's a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but the act
> of doing so would leave a permanent record and many of the people mining on
> his pool would leave. As he doesn't own the actual mining hardware, he then
> wouldn't be able to do it again.
>
Totally see the logic of this, and it makes sense. But I dont think the
only risk is in terms of double spend, but rather
1) vandalize the block chain which may be difficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy lower
As bitcoin's market cap grows, incentives to move the market will grow
>
> There are also other mining protocols that allow people to pool together,
> without p2pool and without the pool operator being able to centrally pick
> which transactions go into the block. However I'm not sure they're widely
> deployed at the moment. It'd be better if people didn't cluster around big
> mining pools, but I think p2pool still has a lot of problems dealing with
> FPGA/ASIC hardware and it hasn't been growing for a long time.
>
I guess the market will decide which algorithm is used, but as a community
we can perhaps review the different mining protocols and order them in
terms of risk ...
>
>
> On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho <melvincarvalho at gmail.com
> > wrote:
>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> Minimize network downtime and maximize team effectiveness.
>> Reduce network management and security costs.Learn how to hire
>> the most talented Cisco Certified professionals. Visit the
>> Employer Resources Portal
>> http://www.cisco.com/web/learning/employer_resources/index.html
>> _______________________________________________
>> 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/20130405/93891a93/attachment.html>

2023-06-07 11:43:22

- 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

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