<unnamed>

Public Key

npub1uvtfvcegcn9kds68r8he57emc480vqtx8t22kpsctxgjxae44gvsksaxrt

Profile Code

nprofile1qqswx95kvv5vfjmxcdr3nmu60vau2nhkq9nr449tqcv9nyfrwu665xgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds07xe2s

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-09 14:54:04 CEST

- 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 14:54:04 CEST

- 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 14:54:03 CEST

- 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 14:49:24 CEST

- 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 17:26:50 CEST

- 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 17:26:46 CEST

- 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 17:25:45 CEST

- 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 17:20:45 CEST

- 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 17:15:34 CEST

- 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 17:11:25 CEST

- 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 17:08:26 CEST

- 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 17:08:25 CEST

- 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 17:07:38 CEST

- 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 17:03:28 CEST

- 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 17:03:06 CEST

- 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 17:03:05 CEST

- 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 17:03:03 CEST

- 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 17:02:57 CEST

- 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 17:02:43 CEST

- 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 17:02:39 CEST

- 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 17:02:26 CEST

- 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 16:56:38 CEST

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

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

- reply

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

2023-06-07 13:42:30 CEST

- reply

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