<unnamed>

Public Key

npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jw

Profile Code

nprofile1qqsfqhefes9frvfz0df346xcgxdsjf465jscxulsckrf8j8n9sn0lfqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqu700hm

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:46:17 CEST

- reply

📅 Original date posted:2015-12-20
📝 Original message:On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
It would be nice if the bip37 filter matching algorithm was extended to
serve up the proof.
And if server-based wallets did the same it would preserve the "just backup
the seed" functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/5a7f7f61/attachment.html>

2023-06-07 19:38:20 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote:
> Fine point.
>
> So where is the solution? What to do?
How about nothing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/5eaae9a9/attachment.html>

2023-06-07 19:37:52 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Aug 28, 2015 7:38 PM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward, it still
requires miners to collectively decide to raise the block size for it to
make sense individually. An individual vote will not raise the limit, but
it will cost the miner money.
>
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> When discussing this with Matt Whitlock earlier we basically concluded
the block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
>>
>> It may be in everyone's collective interest to raise the block size but
not their individual interest.
>>
>> On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> With this proposal, how much would it cost a miner to include an
'extra' 500-byte transaction if the average block size is 900K and it costs
the miner 20BTC in electricity/capital/etc to mine a block?
>>>
>>> If my understanding of the proposal is correct, it is:
>>>
>>> 500/900000 * 20 = 0.11111 BTC
>>>
>>> ... Or $2.50 at today's exchange rate.
>>>
>>> That seems excessive.
>>>
>>> --
>>> Gavin Andresen
>>>
>>>
>>> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > This is the best proposal I've seen yet. Allow me to summarize:
>>> >
>>> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners
selling their block-size votes.
>>> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
trying to predict future market needs versus future technological
capacities.
>>> > • It avoids a large step discontinuity in the block-size limit by
starting with a 1-MB limit.
>>> > • It throttles changes to ±10% every 2016 blocks.
>>> > • It imposes a tangible cost (higher difficulty) on miners who vote
to raise the block-size limit.
>>> > • It avoids incentivizing miners to vote to lower the block-size
limit.
>>> >
>>> > However, this proposal currently fails to answer a very important
question:
>>> >
>>> > • What is the mechanism for activation of the new consensus rule? It
is when a certain percentage of the blocks mined in a 2016-block
retargeting period contain valid block-size votes?
>>> >
>>> >
>>> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>>> >
>>> >
>>> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev
wrote:
>>> >> Pull request: https://github.com/bitcoin/bips/pull/187
>>> > _______________________________________________
>>> > 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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150828/f3f30c1b/attachment.html>

2023-06-07 19:37:51 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
It may be in everyone's collective interest to raise the block size but not
their individual interest.
On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the
> miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
>
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
>
> --
> Gavin Andresen
>
>
> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > This is the best proposal I've seen yet. Allow me to summarize:
> >
> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> their block-size votes.
> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> trying to predict future market needs versus future technological
> capacities.
> > • It avoids a large step discontinuity in the block-size limit by
> starting with a 1-MB limit.
> > • It throttles changes to ±10% every 2016 blocks.
> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> raise the block-size limit.
> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >
> > However, this proposal currently fails to answer a very important
> question:
> >
> > • What is the mechanism for activation of the new consensus rule? It is
> when a certain percentage of the blocks mined in a 2016-block retargeting
> period contain valid block-size votes?
> >
> >
> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >
> >
> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> Pull request: https://github.com/bitcoin/bips/pull/187
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150828/a44dfde3/attachment.html>

2023-06-07 19:37:38 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Aug 21, 2015 2:07 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Also, as I mentioned, just look at the popularity of wallets such as
> Mycelium that are not adopting bloom filters, but going with SPV
> verification of block headers w/ lookup servers.
Related I recently had a conversation with a Mycelium employee who told me
they were considering moving to spv/bloom because of the server issues
Andreas mentioned.
I don't know any more about their plans, but I wouldn't assume the above
statement to be correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/95990bfa/attachment.html>

2023-06-07 19:33:05 CEST

- reply

📅 Original date posted:2015-08-09
📝 Original message:I'm glad Tom is bringing these points up. There seems to be an assumption
by many that LN will be automatically awesome by virtue of it being
technically feasible with having considered whether it is economically
feasible or desirable.
So much stock has been placed in LN as the solution to the block size
debate, yet it could turn out that it sucks in practice. Then what?
On Aug 9, 2015 5:27 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> _______________________________________________
> 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/20150809/db8043fc/attachment.html>

2023-06-07 17:49:17 CEST

- reply

2023-06-07 17:49:16 CEST

- reply

2023-06-07 17:45:17 CEST

- reply

2023-06-07 17:38:36 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>
> * Get safe forms of replace-by-fee and child-pays-for-parent
> finished and in 0.12.
> * Develop cross-platform libraries for managing micropayment
> channels, and get wallet authors to adopt
> * Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim measure
> until:
> * Deploy soft-fork changes for truly scalable solutions like
> Lightning Network.
One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.
Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.
To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/68c14c0e/attachment.html>

2023-06-07 17:20:39 CEST

- reply

📅 Original date posted:2014-05-03
📝 Original message:Absent a concerted effort to move to something else other than 'bits', I
would be willing to bet the nomenclature moves in that direction anyway.
'Bits' is just a shorten word for 'millibits' (or microbits, if you
will). It's easier to say and my guess is people would tend to use it
naturally own their own. Kind of like 'bucks' for dollars.
The other synergies are:
-bit is part of the word Bitcoin. The currency unit bit is part of a
whole bitcoin.
-bit symbolically represents the tech nature of the bitcoin.
-bit used to be a unit of money way back when. This largely reclaims it.
-when used as money bit when in references to a precession metal coin.
The name 'bitcoin' references that as well as the mimicking of the gold
standard in the protocol rules.
All around I don't think there is a better fit. I doubt people will get
confused by it. The context it's used in will distinguish it from other
uses of the word.
On 05/03/2014 12:27 PM, Mike Caldwell wrote:
> I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is "in scope" of our efforts. Getting them to understand computer science at large at the same time, less so.
>
> The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get "horribly" confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should.
>
> Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing.
>
> Mike
>
> Sent from my iPhone
>
>> On May 3, 2014, at 9:49 AM, "Christophe Biocca" <christophe.biocca at gmail.com> wrote:
>>
>> Context as a disambiguator works fine when the interlocutors
>> understand the topics they're talking about.
>> Not a day goes by without me seeing "neurotypical people" get horribly
>> confused between RAM and Hard Drive sizes, because they share the same
>> units (not that that can be helped, as the units are supposed to be
>> the same, base 1000 vs 1024 notwithstanding).
>>
>> Bit (as a unit) is already really confusing for anyone who doesn't
>> deal with it on a regular basis. I think people who don't see an issue
>> are making an assumption based on their own lack of confusion. We
>> understand computer science AND Bitcoin. Most people have zero
>> understanding of either.
>>
>> Bitcoin already has a ton of issues with terrible names for things:
>>
>> - Mining (for transaction validation).
>> - Addresses (which are meant to be one-time use, and don't even really
>> exist at the network level).
>> - Wallets (which don't hold your bitcoins, can be copied, and all
>> backups can be stolen from equally).
>>
>> I end up having to make the distinctions obvious every time I explain
>> Bitcoin to someone new to it. There's an acceptable tradeoff here,
>> because there were arguably no better words to assign to these
>> concepts (although I'd argue mining is a really awful metaphor, and is
>> the one that prompts the most questions from people). Then add to the
>> pile a bunch of third parties naming themselves after parts of the
>> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
>> definitiely seen average people get confused between "the blockchain"
>> and "blockchain.info" (not so much Coinbase, because that name doesn't
>> come up in beginner explanations).
>>
>> It seems downright masochistic to add
>> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
>> for no reason other than aesthetics. Are we actively trying to confuse
>> people?
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:19:33 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:What is the advantage of this proposal over just orphaning the block with
double spends?
There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.
If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
wrote:
> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com>
> wrote:
> >
> >>
> >> And it still would. Non-collusive miners cast votes based on the outcome
> >> of their own attempts to double spend.
> >
> >
> > Individually rational strategy is to vote for coinbase reallocation on
> every
> > block.
> >
> > Yes, in that case nobody will get reward. It is similar to prisoner's
> > dilemma: equilibrium has worst pay-off.
> > In practice that would mean that simple game-theoretic models are no
> longer
> > applicable, as they lead to absurd results.
> >
> >>
> >> I'm using it in the same sense Satoshi used it. Honest miners work to
> >> prevent double spends. That's the entire justification for their
> existence.
> >> Miners that are deliberately trying to double spend are worse than
> useless.
> >
> >
> > Miners work to get rewards.
> > It absolutely doesn't matter whether they are deliberately trying to
> > double-spend or not: they won't be able to double-spend without a
> collusion.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/48d8a89a/attachment.html>

2023-06-07 17:18:57 CEST

- reply

📅 Original date posted:2014-04-20
📝 Original message:You're correct, my impression of the term is based of what I experience in
the US. If it is more widely used in other cultures that should be a
consideration.
On Apr 20, 2014 12:27 PM, "Wladimir" <laanwj at gmail.com> wrote:
> On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia <ctpacia at gmail.com> wrote:
> > The term bit is really only overloaded for those who are techy. 95% of
> the
> > population never uses the term bit in their daily lives and I doubt most
> > could even name one use of the term.
> > Plus bit used to be a unit of money way back when, so this is kind of
> > reclaiming it. I think it's a great fit.
>
> That's a very anglocentric way of thinking.
>
> Here in the Netherlands, a "bit" is something you put in a horses's
> mouth. It's also used as imported word (in the information sense).
> We've never used the term for money.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/9a876d8c/attachment.html>

2023-06-07 17:18:56 CEST

- reply

📅 Original date posted:2014-04-20
📝 Original message:The term bit is really only overloaded for those who are techy. 95% of the
population never uses the term bit in their daily lives and I doubt most
could even name one use of the term.
Plus bit used to be a unit of money way back when, so this is kind of
reclaiming it. I think it's a great fit.
On Apr 20, 2014 11:52 AM, "Alan Reiner" <etotheipi at gmail.com> wrote:
> I've been a staunch supporter of "microbitcoin" and would like to do
> anything I can to make sure that we jump directly to it if we're going to
> promote changing the default units. And I'm happy to integrate it into
> Armory as a default (with appropriate explanations and settings/options).
> I'm not so convinced about the "bits" name though -- I do like it, but I do
> also think that word is too overloaded. Though, I think we could get away
> with it.
>
> (Sadly, I still use "microbes" occasionally (as in *microb*itcoin) when
> I'm talking to coworkers, because it slips off the tongue and is actually a
> good combination of brevity and self-explanatory -- it just doesn't instill
> the right visuals...)
>
> We started integrating alternative units into Armory. But, of course,
> there were a few more loose ends than I expected, which will require some
> work. We want to put it in but not necessarily change the default right
> away. I'd *prefer* we get some commitments from some other wallet
> developers, so we can make a unified push for it. I'm happy to lead that
> and make it default as long as I'm not the only one in the world doing it.
>
> -Alan
>
>
>
> On 04/20/2014 11:05 AM, Tamas Blummer wrote:
>
> Here is an earlier reference to bits:
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html<https://www.mail-archive.com/[email protected]/msg04248.html>
>
> I forgot that Alan Reiner was also supporting a unit equals to bits :
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html<https://www.mail-archive.com/[email protected]/msg04264.html>
>
> and here the earlier going back to March 2013 and a poll at that time
> pushing for XBT being 1 bit
>
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html<https://www.mail-archive.com/[email protected]/msg04256.html>
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> I told him specifically to bring it here (on a pull request for
> Bitcoin Core), as there is no point in making such convention changes
> to just one client.
>
> I wasn't aware of any discussion about the "bits" proposal here before.
>
> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com>
> wrote:
>
> People on this list are mostly engineers who have no problem dealing with
> magnitudes and have rather limited empathy for people who have a problem
> with them.
> They also tend to think, that because they invented money 2.0 they would
> not
> need to care of finance's or people's current customs.
>
> The importance of their decisions in these questions will fade as people
> already use wallets other than the core.
>
> Bring this particular discussion elsewhere, to the wallet developer.
>
> BTW the topic was discussed here several times, you have my support and
> Jeff
> Garzik's.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com><rob.golding at astutium.com>wrote:
>
> The average person is not going to be confident that the prefix they
> are using is the correct one,
>
>
> The use of any 'prefix' is one of choice and entirely unnecessary, and
> there
> are already established 'divisions' in u/mBTC for those that feel they need
> to use such things.
>
> people WILL send 1000x more or less than
> intended if we go down this road,
>
>
> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
> once in 20 years has anyone ever 'sent' more or less than intended - oh,
> they've 'intended' to underpay just fine, but never *unintended*.
>
> I propose that users are offered a preference to denominate the
> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
> equals one million bits (bits) and one bit equals 100 satoshis.
>
>
> I propose that for people unable to understand what a bitcoin is, they can
> just use satoshi's and drop this entire proposal.
>
> Rob
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://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/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/20140420/46548050/attachment.html>