<unnamed>

Public Key

npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksaj

Profile Code

nprofile1qqs25hx4ztc48am65v6aw9un7txjr9tfrz9wm27h6q3e8p430amj3kqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsl97mls

Publishing to

relay.damus.io

nos.lol

relay.primal.net

Last Notes

2023-06-07 18:30:09 UTC

- reply

📅 Original date posted:2021-03-06
📝 Original message:As said before, you are free to create the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR
Lonero Foundation via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> escreveu no dia sábado,
6/03/2021 à(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running on AWS, I heard the same thing is for Bitcoin but for mining. Had trouble finding the article online so take it with a grain of salt. The point though is that both servers and ASIC specific hardware would still be able to benefit from the cryptography upgrade I am proposing, as this was in relation to the disinfranchisemet point.
>
> That said, I think the best way to move forward is to submit a BIP pull request for a draft via GitHub using BIP #2's draft format and any questions people have can be answered in the reqeust's comments. That way people don't have to get emails everytime there is a reply, but replies still get seen as opposed to offline discussion. Since the instructions say to email bitcoin-dev before doing a bip draft, I have done that. Since people want to see the draft beforehand and it isn't merged manually anyways, I think it is the easiest way to handle this.
>
> I'm also okay w/ continuing the discussion on bitcoin-dev but rather form a discussion on git instead given I don't want to accidentally impolitely bother people given this is a moderated list and we already established some interest for at least a draft.
>
> Does that seem fine?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland at gmail.com> wrote:
>>
>> > A large portion of BTC is already mined through AWS servers and non-asic specific hardware anyways. A majority of them would benefit from a hybrid proof, and the fact that it is hybrid in that manner wouldn't disenfranchise currently optimized mining entities as well.
>>
>> My instincts tell me that this is an outlandish claim. Do you have supporting evidence for this?
>>
>> Keagan
>>
>> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Actually I mentioned a proof of space and time hybrid which is much different than staking. Sorry to draw for the confusion as PoC is more commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Work as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of being both CPU compatible and memory-hard compatible. There are lots of benefits outside of the realm of efficiency, and I already looked into numerous fault tolerant designs as well and what others in the cryptography community attempted to propose. The actual argument you have only against this is the Proof of Memory fallacy, which is only partially true. Given how the current hashing algorithm works, hard memory allocation wouldn't be of much benefit given it is more optimized for CPU/ASIC specific mining. I'm working towards a hybrid mechanism that fixes that. BTW: The way Bitcoin currently stands in its cryptography still needs updating regardless. If someone figures out NP hardness or the halting problem the traditional rule of millions of years to break all of Bitcoin's cryptography now comes down to minutes. Bitcoin is going to have to eventually radically upgrade their cryptography and hashing algo in the future regardless. I want to integrate some form of NP complexity in regards to the hybrid cryptography I'm aiming to provide which includes a polynomial time algorithm in the cryptography. More than likely the first version of my BTC hard fork will be coded in a way where integrating such complexity in the future only requires a soft fork or minor upgrade to its chain.
>>>
>>> In regards to the argument, "As a separate issue, proposing a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining entities and disincentivize future capital expenditure into mining hardware that may compute these more "useful" proofs of work."
>>>
>>> A large portion of BTC is already mined through AWS servers and non-asic specific hardware anyways. A majority of them would benefit from a hybrid proof, and the fact that it is hybrid in that manner wouldn't disenfranchise currently optimized mining entities as well.
>>>
>>> There are other reasons why a cryptography upgrade like this is beneficial. Theoretically one can argue BItcoin isn't fully decentralized. It is few unsolved mathematical proofs away from being entirely broken. My goal outside of efficiency is to build cryptography in a way that prevents such an event from happening in the future, if it was to ever happen. I have various research in regards to this area and work alot with distributed computing. I believe if the BTC community likes such a proposal, I would single handedly be able to build the cryptographic proof myself (though would like as many open source contributors as I can get :)
>>>
>>> Anyways just something to consider. We are in the same space in regards to what warrants a shitcoin or the whole argument against staking.
>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>>>
>>> Best regards, Andrew
>>>
>>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland at gmail.com> wrote:
>>>>
>>>> It is important to understand that it is critical for the work to be "useless" in order for the security model to be the same. If the work was useful it provides an avenue for actors to have nothing at stake when submitting a proof of work, since the marginal cost of block construction will be lessened by the fact that the work was useful in a different context and therefore would have been done anyway. This actually degrades the security of the network in the process.
>>>>
>>>> As a separate issue, proposing a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining entities and disincentivize future capital expenditure into mining hardware that may compute these more "useful" proofs of work. This is because any change in the POW algorithm will be considered unstable and subject to change in the future. This puts the entire network at even more risk meaning that no entity is tying their own interests to that of the bitcoin network at large. It also puts the developers in a position where they can be bribed by entities with a vested interest in deciding what the new "useful" proof of work should be.
>>>>
>>>> All of these things make the Bitcoin network worse off.
>>>>
>>>> Keagan
>>>>
>>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Also in regards to my other email, I forgot to iterate that my cryptography proposal helps behind the efficiency category but also tackles problems such as NP-Completeness or Halting which is something the BTC network could be vulnerable to in the future. For sake of simplicity, I do want to do this BIP because it tackles lots of the issues in regards to this manner and can provide useful insight to the community. If things such as bigger block height have been proposed as hard forks, I feel at the very least an upgrade regarding the hashing algorithm and cryptography does at least warrant some discussion. Anyways I hope I can send you my BIP, just let me know on the preferred format?
>>>>>
>>>>> Best regards, Andrew
>>>>>
>>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation at gmail.com> wrote:
>>>>>>
>>>>>> Hi, this isn't about the energy efficient argument in regards to renewables or mining devices but a better cryptography layer to get the most out of your hashing for validation. I do understand the arbitrariness of it, but do want to still propose a document. Do I use the Media Wiki format on GitHub and just attach it as my proposal?
>>>>>>
>>>>>> Best regards, Andrew
>>>>>>
>>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>>>>>>>
>>>>>>> Hi Ryan and Andrew,
>>>>>>>
>>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/
>>>>>>>> "Nothing is Cheaper than Proof of Work"
>>>>>>>> on | 04 Aug 2015
>>>>>>>>
>>>>>>>
>>>>>>> Just to belabor this a bit, the paper demonstrates that the mining market will tend to expend resources equivalent to miner reward. It does not prove that mining work has to expend *energy* as a primary cost.
>>>>>>>
>>>>>>> Some might argue that energy expenditure has negative externalities and that we should move to other resources. I would argue that the negative externalities will go away soon because of the move to renewables, so the point is likely moot.
>>>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:46:15 UTC

- reply

📅 Original date posted:2015-12-13
📝 Original message:I really like ideas that tackle this issue. The question imho is what is
the incentive to run a "Full UTXO node" instead of a pruned or archive node.
For starters, it would be nice to know what would be the savings for Full
UTXO nodes over archive nodes right now.
Also, what advantages would this have over "archive pruned nodes: nodes
that store X blocks of the whole blockchain before 420000". Seems like an
interesting intermediate use case to me too.
2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe at gmail.com>
> wrote:
>
>> What is the current behavior / cost that this proposal is trying to
>> avoid? Are ancient utxos required to be kept in memory always in a fully
>> validating node, or can ancient utxos get pushed out of memory like a
>> normal LRU caching db?
>>
>
> I don't see why it must be kept in memory. But storage is still a problem.
> With the 8 year limit and a fixed max block size, it indirectly sets an
> upper limit for UTXO set.
>
>
> Chris Priest via bitcoin-dev :
>
>> This isn't going to kill bitcoin, but it won't make it any better.
>>
>
> Do you believe that thousands of volunteer full nodes are obliged to store
> an UTXO record, just because one paid US$0.01 to an anonymous miner 100
> years ago? It sounds insanely cheap, isn't it? My proposal (or similar
> proposal by Peter Todd) is to solve this problem. Many commercial banks
> have a dormant threshold less than 8 years so I believe it is a balanced
> choice.
>
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
> Currently, if one holds nothing but a private key, he must consult either
> an archive node or a full UTXO node for the latest UTXO state to spend his
> coin. We currently do not have any lite UTXO node, and such node would not
> work properly beyond block 420000.
>
> With the softfork I described in my original post, if the UTXO is created
> within the last 420000 blocks, the key holder may consult any type of full
> node, including a lite UTXO node, to create the transaction.
>
> If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
> node obviously can't provide the necessary information to spend the coin.
> However, not even a full UTXO node may do so. A full UTXO node could tell
> the position of the UTXO in the blockchain, but can't provide all the
> information required by my specification. Only an archive node may do so.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
> It is not possible to construct the membership prove I require without
> these information. It is designed this way, so that lite UTXO nodes won't
> need to store any dormant UTXO records: not even the hash of individual
> dormant UTXO records. If the blockchain grows to insanely big, it may take
> days or weeks to retrieve to records. However, I don't think this is
> relevant as one has already left his coins dormant for >8 years. Actually,
> you don't even need the full blockchain. For (1), all you need is the
> 420000 blocks from Y to Y+420000 minus any witness data, as you don't need
> to do any validation. For (2), you just need the coinbase of Y+420001 to
> present, where any spending would have been committed, and retrieve the
> full block only if a spending is found.
>
> So the Bitcoin Bank (miners) is not going to shred your record and
> confiscate your money. Instead, the Bank throws your record to the garage
> (raw blockchain). You can search for your record by yourself, or employ
> someone (archive node) to search it for you. In any case it incurs costs.
> But as thousands of bankers have kept your record on their limited desk
> space for 8 years for free (though one of them might receive a fraction of
> a penny from you), you shouldn't complain with any moral, technical, or
> legal reason. And no matter what users say, I believe something like this
> will happen when miners and full nodes can't handle the UTXO set.
>
> I'd like to see more efficient proposals that archive the same goals.
>
> p.s. there were some typos in my original. The second sentence of the
> second paragraph should be read as "For every block X+420000, it will
> commit to a hash for all UTXOs generated in block X."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
> Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
> DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
> Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
> PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
> lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
> VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
> zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
> EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
> =2xRy
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> 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/20151213/67eaba28/attachment.html>

2023-06-07 15:35:59 UTC

- reply

📅 Original date posted:2015-05-31
📝 Original message:2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong at gmail.com>:
>
>
> On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe at gmail.com>
> wrote:
>>
>> He also said that the equation for miners has many variables, as it
>> should. There is no disadvantage if the network speed is the same
>> between the miners.
>
>
> Hi,
>
> Is that an assumption?
no, let me rephrase: The disadvantage alex refers to only exists if
miners do not have the same network speed.
>
>> If there is a difference in network speed, the
>> miner is incentivized to invest in their network infrastructure.
>
>
> Perhaps it's best not to assume that investing in Internet network
> infrastructure's a free or open market everywhere.
Just like easy ASIC access, low price electricity, etc are not a free
and open market.
>
> p.
>
>>
>>
>> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> >> Yes, if you are on a slow network then you are at a (slight)
>> >> disadvantage.
>> >> So?
>> >
>> >
>> > Chun mentioned that his pool is on a slow network, and thus bigger
>> > blocks
>> > give it an disadvantage. (Orphan rate is proportional to block size.)
>> > You said that no, on contrary those who make big blocks have a
>> > disadvantage.
>> > And now you say that yes, this disadvantage exist.
>> >
>> > Did you just lie to Chun?
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://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
>
>

2023-06-07 15:35:59 UTC

- reply

📅 Original date posted:2015-05-31
📝 Original message:He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between the miners. If there is a difference in network speed, the
miner is incentivized to invest in their network infrastructure.
2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
> You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
> Did you just lie to Chun?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:31:26 UTC

- reply

📅 Original date posted:2015-03-11
📝 Original message:i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in standards as our industries have in
the past...
2015-03-11 19:04 GMT+00:00 Jim <jim618 at fastmail.co.uk>:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
>
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
>
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
>
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
>
> --
> http://bitcoin-solutions.co.uk
>
> On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
>> Sigh. The wallet words system is turning into kind of a mess.
>>
>> I thought the word list is in fact not a fixed part of the spec, because
>> the entropy is a hash of the words. But perhaps I'm misunderstanding
>> something.
>>
>> The main problem regular SPV wallets have with BIP39 is that there is no
>> birth time included in the data. Therefore we must ask users to write down
>> a timestamp as well, so we know where to start rescanning the chain. It
>> sounds like the Electrum version doesn't fix this, so now we have at least
>> FIVE incompatible results from a 12 word list:
>>
>> - Electrum v2 with a version number but no date
>> - myTREZOR with no version and no date and BIP44 key derivation. Some
>> seeds I believe are now being generated with 24 words instead of 12.
>> - MultiBit HD with no version and a date in a custom form that creates
>> non-date-like codes you are expected to write down. I think BIP32 and BIP44
>> are both supported (sorta).
>> - GreenAddress with no version, no date and BIP32
>> - Other bitcoinj based wallets, with no version and a date written down
>> in normal human form, BIP32 only.
>>
>> I really hope we can recover from this somehow because otherwise all
>> wallets will have to provide the user with a complicated matrix of
>> possibilities and software combinations, and in practice many won't bother
>> so these word combinations will actually end up being wallet specific for
>> no particularly good reason, just very minor details like the presence or
>> absence of single fields.
>>
>> It feels like we somehow fell flat on our faces just before the finishing
>> line. This is deeply unfortunate. Compatibility and UX consistency is
>> important!
>>
>> Currently, I don't have any bright ideas for how to get everyone back onto
>> the same page with a fully compatible system that is acceptable to all. If
>> anyone else has suggestions, I'm all ears.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:17:41 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:Or have blocks distributed through pruned nodes as a DHT.
2014-04-07 20:13 GMT+01:00 Mark Friedenbach <mark at monetize.io>:
>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do you find those blocks?
>
> I have a suggestion: have nodes advertise which range of full blocks
> they possess, then you can perform synchronization from the adversed ranges!
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:17:32 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:phasing out of bitcoinqt into spv wallets?
2014-04-07 12:34 GMT+01:00 Mike Hearn <mike at plan99.net>:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
> http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people might stop running a node (uses too much
> disk space, bandwidth, lost interest etc). But does anyone have any idea how
> we might get more insight into what's really going on? It'd be convenient if
> the subVer contained the operating system, as then we could tell if the
> bleed was mostly from desktops/laptops (Windows/Mac), which would be
> expected, or from virtual servers (Linux), which would be more concerning.
>
> When you set up a Tor node, you can add your email address to the config
> file and the Tor project sends you emails from time to time about things you
> should know about. If we did the same, we could have a little exit survey:
> if your node disappears for long enough, we could email the operator and ask
> why they stopped.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:17:20 UTC

- reply

📅 Original date posted:2014-04-07
📝 Original message:2014-04-07 21:08 GMT+01:00 Troy Benjegerdes <hozer at hozed.org>:
> I have to play dissenter here again..
>
> Using a bitcoin address as a persistent identity key is the first real-world
> use of Bitcoin that I can imagine will make it a 'killer app' that everyone
> and their grandma will want to use.
>
I am of the same opinion, although i understand Gavin's point. Would
the multisig seed work for this purpose?
I have been toying with this idea and I think that for this BIP to
make sense it would require a "root" key as your login. Then if you
need to make transfers the system would request you to create and
associate a new key to your account for each purchase (signing the new
key with the root one for example).

2023-06-07 15:16:07 UTC

- reply

📅 Original date posted:2014-03-25
📝 Original message:2014-03-25 13:49 GMT+00:00 Peter Todd <pete at petertodd.org>:
> On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
>> On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:
>>
>> > Bitcoin doesn't scale. There's a lot of issues at hand here, but the
>> > most fundemental of them is that to create a block you need to update
>> > the state of the UTXO set, and the way Bitcoin is designed means that
>> > updating that state requires bandwidth equal to all the transaction
>> > volume to keep up with the changes to what set. Long story short, we get
>> > O(n^2) scaling, which is just plain infeasible.
>> >
>>
>> We have a fundamental disagreement here.
>>
>> If you go back and read Satoshi's original thoughts on scaling, it is clear
>> that he imagined tens of thousands of mining nodes and hundreds of millions
>> of lightweight SPV users.
>
> Yeah, about that...
>
> https://blockchain.info/pools
>
On-topic:
This argument is quite the fallacy. The only reason we have that few
pools is because each of their miners doesn't find it feasible to mine
"on their own". if you count the individual miners on those pools you
will get to the scale Gavin was trying to point out.
Nevertheless i think that is just a minor disagreement, since tree
chains help decentralization.
> For someone with 'Chief Scientist' as their job title, I'm surprised you
> think so little of hard evidence and so much of idol worshipping.
>
>
> P.S. A year or so ago you complained that if I cared so much about
> decentralization, I should make P2Pool better. Your homework: What do
> tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do
> with that? What about the cube-square law? And why don't I think TXO
> commitments solve the blocksize problem?
>
> 1) https://bitcointalk.org/index.php?topic=309073.0;all
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000020366a15799010ae0432be831c197e06b19133028a9aa6f3
>
> ------------------------------------------------------------------------------
> 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
>

2023-06-07 15:15:29 UTC

- reply

📅 Original date posted:2014-03-14
📝 Original message:so much discussion for a visual update...
make this a user experiment:
-give the user the possibility to use BTC/mBTC/uMTC
-retrieve the results after some time
-make the default the most used option
2014-03-14 16:15 GMT+00:00 Alex Morcos <morcos at gmail.com>:
> I think Mark makes some good arguments.
> I realize this would only add to the confusion, but...
> What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
> whatever else), with a proper 3 letter code, and then from a user
> standpoint, where people are using mBTC, they could switch to using Kbits
> (ok thats obviously bad, but you get the idea) at the same nominal price.
> But accounting backends and so forth would operate in the "bit" base unit
> with 2 decimals of precision.
>
>
>
>
> On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark at monetize.io> wrote:
>>
>> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
>> numbers in both Chinas, Thailand, and other economically important East
>> Asian countries. Expect to pay hundreds of rupees in India, or thousands
>> of rupees in Indonesia.
>>
>> This concept that money should have low, single digits for everyday
>> prices is not just Western-centric, it's English-centric. An expresso in
>> Rome would have cost you a few (tens of?) thousand lira in recent
>> memory. It was pegging of the Euro to the U.S. dollar that brought
>> European states in line with the English-speaking world (who themselves
>> trace lineage to the pound sterling).
>>
>> No, there is no culturally-neutral common standards for currency and
>> pricing. But there are ill-advised, ill-informed "standards" in
>> accounting software that we nevertheless must live with. These software
>> packages do not handle more than two decimal places gracefully. That
>> gives technical justifications for moving to either uBTC or accounting
>> in Satoshis directly. An argument for uBTC is that it retains alignment
>> with the existing kBTC/BTC/mBTC/uBTC conventions.
>>
>> However another limitation of these accounting software practices is
>> that they do not always handle SI notation very well, particularly
>> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
>> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
>> compliant with any software accounting package out there.
>>
>> We are still very, very early in the adoption period. These are changes
>> that could be made now simply by a few big players and/or the bitcoin
>> foundation changing their practice and their users following suit.
>>
>> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
>> > How much do you pay for an Espresso in your local currency?
>> >
>> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>> > people would expect. Certainly more familiar than µBTC 3558 or BTC
>> > 0.003578.
>> >
>> > Anyway, I was just sharing real-world experience: nobody is confused.
>> >
>> >
>> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> >> You give them a hard to interpret thing like mBTC and then wonder
>> >> why they rather look at local currency. Because the choices you
>> >> gave them are bad.
>> >>
>> >> I think Bitcoin would have a better chance to be percieved as a
>> >> currency of its own if it had prices and fractions like currencies
>> >> do.
>> >>
>> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> >> would be.
>> >>
>> >>
>> >> Tamas Blummer Bits of Proof
>> >>
>> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas at schildbach.de>
>> >> wrote:
>> >>
>> >>> btw. None of Bitcoin Wallet's users complained about confusion
>> >>> because of the mBTC switch. In contrast, I get many mails and
>> >>> questions if exchange rates happen to differ by >10%.
>> >>>
>> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
>> >>> local currency that matters to the users.
>> >>>
>> >>>
>> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
>> >>>> µBTC.
>> >>>>
>> >>>> I must admit I was not aware if this thread. I just watched
>> >>>> other wallets and at some point decided its time to switch to
>> >>>> mBTC.
>> >>>>
>> >>>>
>> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>> >>>>> The standard has become mBTC and that's what was adopted.
>> >>>>> It's too late to try and sway this on a mailing list thread
>> >>>>> now.
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>> >>>>> <g.rowe at froot.co.uk <mailto:g.rowe at froot.co.uk>> wrote:
>> >>>>>
>> >>>>> The MultiBit HD view is that this is a locale-sensitive
>> >>>>> presentation issue. As a result we offer a simple
>> >>>>> configuration panel giving pretty much every possible
>> >>>>> combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
>> >>>>> mXBT, μXBT, sat along with settings for leading/trailing
>> >>>>> symbol, commas, spaces and points. This allows anyone to
>> >>>>> customise to meet their own needs beyond the offered default.
>> >>>>>
>> >>>>>
>> >>>>> We apply the NIST guidelines for representation of SI unit
>> >>>>> symbols (i.e no conversion to native language, no RTL giving
>> >>>>> icon+m etc).
>> >>>>>
>> >>>>> Right now MultiBit HD is configured to use m+icon taken from
>> >>>>> the Font Awesome icon set. However reading earlier posts it
>> >>>>> seems that μ+icon is more sensible.
>> >>>>>
>> >>>>> Let us know what you'd like.
>> >>>>>
>> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>> >>>>> Awesome icon:
>> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>> >>>>>
>> >>>>>
>> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik at bitpay.com
>> >>>>> <mailto:jgarzik at bitpay.com>> wrote:
>> >>>>>
>> >>>>> Resurrecting this topic. Bitcoin Wallet moved to mBTC
>> >>>>> several weeks ago, which was disappointing -- it sounded like
>> >>>>> the consensus was uBTC, and moving to uBTC later --which will
>> >>>>> happen-- may result in additional user confusion, thanks to
>> >>>>> yet another decimal place transition.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w at grabhive.com
>> >>>>> <mailto:w at grabhive.com>> wrote:
>> >>>>>> We're with uBTC too. Been waiting for the signal to do
>> >>>>>> this,
>> >>>>> let's do it right after the fee system is improved.
>> >>>>>>
>> >>>>>> -wendell
>> >>>>>>
>> >>>>>> grabhive.com <http://grabhive.com> |
>> >>>>>> twitter.com/hivewallet
>> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>> >>>>>>
>> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>> >>>>>>
>> >>>>>>> Go straight to uBTC. Humans and existing computer
>> >>>>>>> systems
>> >>>>> handle numbers to
>> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>> >>>>>>> The
>> >>>>> opposite is
>> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
>> >>>>>>> places).
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -- Jeff Garzik Bitcoin core developer and open source
>> >>>>> evangelist BitPay, Inc. https://bitpay.com/
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------------------------
>> >>>>>
>> >>>>>
>> > 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
>> >>>>> <mailto: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
>> >>>>> <mailto: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
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>
>> >
>> > ------------------------------------------------------------------------------
>> >>>> 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
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >>
>> >>
>> > 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
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>