Drak [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-11-05 to 2014-08-23
💬 Posted a total of 59 messages
📚 Participated in the following categories: Bitcoin-development, unSYSTEM
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub12rkw0jajmsck4uwdtksdvtswrlkypusfryjzera7m4fhqta6jhdsz3aqxc

Profile Code

nprofile1qqs9pm88ewedcvt278x4mgxk9c8plmzq7gy3jfpv37ld65ms97aftkcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsju043k

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub12rkw0jajmsck4uwdtksdvtswrlkypusfryjzera7m4fhqta6jhdsz3aqxc

Show more details

Last Notes

2023-06-07 17:25:32

- reply

📅 Original date posted:2014-08-23
📝 Original message:On 23 August 2014 12:38, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> That allows using github as easy-access mechanism for people to
> contribute and inspect, while having a higher security standard for
> the actual changes done to master.
I'd also like to point out the obvious: git uses the previous hash as part
of the formula to generate the current commit hash thus tampering with
history while possible would be instantly noticed because we all have
copies of the repository. Tampering would be completely evident (pushes
would fail for a start, and even simple merges would bork). It's just not
possible to tamper with the repository without it being discovered, even
with collusion (or strong arming) of github.
The social benefits of github make it idea for open source projects that
want community participation. The barrier to entry is low. The only "weak"
spot of github is the releases section, but since we don't actually
distribute Bitcoin from github the point is moot.
I think github haters fail to see the vast benefits of a social hub like
github. Their issue tracker may not be as sophisticated, it serves well and
the project is extremely productive.
Don't shoot yourself in the foot - a move away from github would be a
disaster for the project.
When you look at the attack surface of using github, it's pretty small and
would not go unnoticed, thus nullifying concern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/de3856a5/attachment.html>

2023-06-07 17:23:32

- reply

📅 Original date posted:2014-07-04
📝 Original message:*watches the tumble weed blow by*
I think it's pretty safe to remove it...
On 4 July 2014 08:15, Wladimir <laanwj at gmail.com> wrote:
> On Wed, Jun 11, 2014 at 5:39 PM, Wladimir <laanwj at gmail.com> wrote:
>
> > If no one screams fire, we plan on removing support for it in the next
> > major release, for two reasons:
> >
> > - It would remove some crufty, hardly tested code paths
> >
> > - SOCKS5 offers better privacy as it allows DNS redirection
>
> Another one:
>
> - SOCKS5 supports IPv6
>
> Last call...
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> 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/20140704/3c7d956e/attachment.html>

2023-06-07 17:20:39

- reply

📅 Original date posted:2014-05-04
📝 Original message:+1
On 4 May 2014 02:06, "Chris Pacia" <ctpacia at gmail.com> wrote:
> 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
> >
>
>
>
> ------------------------------------------------------------------------------
> "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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140504/8203ed3c/attachment.html>

2023-06-07 17:19:32

- reply

📅 Original date posted:2014-04-23
📝 Original message:Cut it out with the ad hominem attacks please. If you cant be civil, please
go away until you learn some manners.
I think the issue being discussed is do you orphan an entire block causing
distress to users as well, or try to just cause distress just to the evil
miner? This discussion is about exploring the ramifications of all these
options.
I think you are also forgetting that, miners can implement their own
filters and behaviours without anyone's consent. So having an open
discussion and exploring all possibilities can only be a good thing before
someone goes off an implements a change without taking into account other
points of view they may not have considered yet.
On 23 Apr 2014 19:51, "Justus Ranvier" <justusranvier at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/23/2014 06:37 PM, Mike Hearn wrote:
> > If you want to try and argue that the development list is the wrong
> > place to discuss development, please do so on another thread (or
> > your blog). Let's keep this thread for discussion of the original
> > proposal - ideally, discussed with the dryness that a topic as
> > nerdy as distributed consensus algorithms deserves ;)
> >
>
> Is that what you say to yourself to quiet your conscience at night
> (assuming you're one of the non-sociopathic humans who does indeed
> have one)? It's "just a nerdy distributed consensus problem"?
>
> The things you're talking about fucking around with have real life
> implications for quite a few people and your casual dismissal of this
> is precisely why I responded in the way that I did.
>
> What you're doing is reckless endangerment and you're not got to get
> away with brushing it off as a mere technical detail.
>
> Sunlight is the best disinfectant, and this episode is demonstrating
> to the world exactly how averse you are do that kind of transparency.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
> 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
> V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
> QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
> aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
> ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
> =L5nX
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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/1fa69efc/attachment.html>

2023-06-07 17:17:44

- reply

📅 Original date posted:2014-04-07
📝 Original message:For what it's worth, the number of nodes rose dramatically during the China
bullrun (I recall 45k in China alone) and dropped as dramatically as the
price after the first PBOC announcement designed to cool down bitcoin
trading in China.
On 7 April 2014 12:34, Mike Hearn <mike at plan99.net> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/8869112e/attachment.html>

2023-06-07 17:15:38

- reply

📅 Original date posted:2014-03-13
📝 Original message:I agree with you Jeff. The unit switch needs to happen once and once only,
but that is exactly why I said the defaults really need to change in
Bitcoin-Qt since that is still the main reference implementation and it
will influence others.
Bitpay could also take the lead here and make the switch to their defaults.
That would greatly assist the uBTC movement.
Regardless of what anyone says, Bitcoin-Qt is still the main reference
implementation and the best way to encourage a change in the community at
large is for the default units to be changed here. Core devs can surely
garner enough consensus among themselves to accept and merge a PR to that
effect. That will send a message, more than anything else that can be done.
My two satoshi.
Drak
On 13 March 2014 16:29, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> > Of course, as Mike said, this ship may have already sailed, but if
> > there's any way to revisit this, I'm there. We're just about to do
> > another Armory release and could support this very easily.
>
> mBTC now just means the issue -will- be revisited in the future. Just
> a question of when, not if.
>
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
>
> <vendor hat: on> To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
>
> I also argue that it is a security risk, as follows: To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed. This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software. That, in turn, making auditing more
> difficult, particularly for outsiders.
>
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
>
> --
> 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
> 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/ed4f62d7/attachment.html>

2023-06-07 17:15:01

- reply

📅 Original date posted:2014-03-10
📝 Original message:I was wondering if there would be merit in a kind of BIP for a payment
protocol using multisig?
Currently, setting up a multisig is quite a feat. Users have to exchange
public keys, work out how to get the public keys from their addresses. If
one of the parties are not savvy enough, an malicious party could easily be
setup that was 2 of 3 instead of 2 of 2 where the malicious party generates
the multisig address+script and thus be able to run off with funds anyway.
It's also terribly complex to generate and keep track of. There's been a
nice attempt at creating an browser interface at coinb.in/multisig but it
still lacks the kind of ease with created by the payment protocol. If there
was a BIP then it would go a long way to aiding future usability of
multisig wallet implementations.
What are your thoughts?
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/0b5ecd92/attachment.html>

2023-06-07 17:14:33

- reply

📅 Original date posted:2014-03-02
📝 Original message:On 2 March 2014 20:40, Peter Todd <pete at petertodd.org> wrote:
> I proof-read rc1 and simply submitted my changes via pull-req:
>
> https://github.com/bitcoin/bitcoin/pull/3642
>
> I'd say to encourage that method. If someone doesn't know how to use
> git, yet still wants to proof-read, just send us a text-file with all
> your corrections applied. We've got the tools to diff those changes
> ourselves; no fancy software is required.
Actually, this is unnecessary since github allows editing of files directly
on the site and the it will submit as a pull request. You can even update
by visiting your fork (it creates this automatically and a topic branch)
and make more edits and it will add to your PR. There is basically no
barrier for non techy people to contribute.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140302/3e12d3e3/attachment.html>

2023-06-07 17:13:36

- reply

📅 Original date posted:2014-02-10
📝 Original message:Well done Gavin for quickly setting the record straight[1] officially as
project lead. MtGox tried to blame their issues by throwing Bitcoin under a
bus and I am glad there has been a public rebuttal showing up their
incompetence which is doing harm to the bitcoin eco system. Basically, yes
there are issues, but MtGox should have worked around it.
Also thanks to Gregory for also writing[2] about the matter.
Drak
[1] https://bitcoinfoundation.org/blog/?p=418
[2]
http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140210/f7a24071/attachment.html>

2023-06-07 17:13:33

- reply

📅 Original date posted:2014-02-10
📝 Original message:What is the official response from the Bitcoin Core developers about
MtGox's assertion that their problems are due to a fault of bitcoin, as
opposed to a fault of their own?
The technical analysis preluding this mess, was that MtGox was at fault for
their faulty wallet implementation.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140210/dd667928/attachment.html>

2023-06-07 17:11:47

- reply

📅 Original date posted:2014-01-17
📝 Original message:That could also work. Still, didn't we want to ditch the word address?
Could be a privacy key...
On 17 Jan 2014 09:15, "Mike Hearn" <mike at plan99.net> wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"? As Peter
> notes, that's what people actually like and want. The problem with stealth
> is it's got strong connotations with American military hardware and perhaps
> thieves sneaking around in the night:
>
> https://www.google.com/search?tbm=isch&q=stealth
>
> But everyone loves privacy.
>
>
> On Fri, Jan 17, 2014 at 8:49 AM, Drak <drak at zikula.org> wrote:
>
>> Peter I agree with you about "reusable addresses", but aren't we also
>> trying to get away from the word "address" entirely? How about calling it
>> a "payment key" or "reusable payment key" instead? using "stealth" is just
>> asking for bad press imo.
>>
>>
>> On 16 January 2014 21:28, Peter Todd <pete at petertodd.org> wrote:
>>
>>> On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
>>> > Might I propose "reusable address".
>>> >
>>> > I think that describes it best to any non-programmer, and even more
>>> > so encourages wallets to present options as 'one time use' vs
>>> > 'reusable'.
>>> >
>>> > It definitely packs a marketing punch which could help drive
>>> > adoption. The feature is only useful if/when broadly adopted.
>>>
>>> I'm very against the name "reusable addresses" and strongly belive we
>>> should stick with the name stealth addresses.
>>>
>>> You gotta look at it from the perspective of a user; lets take standard
>>> pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many
>>> times as I want and everything works just great. I also can enter the
>>> address on blockchain.info's search box, and every transaction related
>>> to the address, and the balance of it, pops up immediately.
>>>
>>> What is that telling me? A: Addresses starting with "1" are reusable. B:
>>> Transactions associated with them appear to be public knowledge.
>>>
>>> Now I upgrade my wallet software and it says I now have a "reusable"
>>> address. My reaction is "Huh? Normal addresses are reusable, what's
>>> special about this weird reusable address thing that my buddy Bob's
>>> wallet software couldn't pay." I might even try to enter in a "reusable"
>>> address in blockchain.info, which won't work, and I'll just figure
>>> "must be some new unsupported thing" and move on with my life.
>>>
>>> On the other hand, suppose my wallet says I now have "stealth address"
>>> support. I'm going to think "Huh, stealth? I guess that means privacy
>>> right? I like privacy." If I try searching for a stealth address on
>>> blockchain.info, when it doesn't work I might think twig on "Oh right!
>>> It said stealth addresses are private, so maybe the transactions are
>>> hidden?" I might also think "Maybe this is like stealth/incognito mode
>>> in my browser? So like, there's no history being kept for others to
>>> see?" Regardless, I'm going to be thinking "well I hear scary stuff
>>> about Bitcoin privacy, and this stealth thing sounds like it's gonna
>>> help, so I should learn more about that"
>>>
>>> Finally keep in mind that stealth addresses have had a tonne of very
>>> fast, and very wide reaching PR. The name is in the public conciousness
>>> already, and trying to change it now just because of vague bad
>>> associations is going to throw away the momentum of that good PR and
>>> slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I
>>> based on conversations there with people there, technical and
>>> non-technical, almost everyone had heard about them and almost everyone
>>> seemed to understand the basic idea of why they were a good thing. That
>>> just wouldn't have happened with a name that tried to hide what stealth
>>> addresses were for, and by changing the name now we risk people not
>>> making the connection when wallet software gets upgraded to support
>>> them.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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/20140117/521c0ff2/attachment.html>

2023-06-07 17:11:21

- reply

📅 Original date posted:2014-01-03
📝 Original message:On 3 January 2014 05:45, Troy Benjegerdes <hozer at hozed.org> wrote:
> On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote:
> > On Tue, Dec 31, 2013 at 5:39 AM, Drak <drak at zikula.org> wrote:
> > > The NSA has the ability, right now to change every download of
> bitcoin-qt,
> > > on the fly and the only cure is encryption.
>
> No, the only cure is the check the hashes. We should know something
> about hashes here. TLS is a big pile of 'too big to audit'. Spend
> a couple of satoshis and put the hash of the source tar.gz and the
> binaries in the blockchain. Problem solved.
Which is why, as pointed out several times at 30c3 by several renowned
figures, why cryptography has remained squarely outside of mainstream use.
It needs to just work and until you can trust the connection and what the
end point sends you, automatically, it's a big fail and the attack vectors
are many.
<sarcasm>I can just see my mother or grandma manually checking the hash of
a download... </sarcasm>
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/37cd808c/attachment.html>

2023-06-07 17:10:54

- reply

📅 Original date posted:2013-12-19
📝 Original message:How does signing the commit message itself help at all since it just signs
the commit message, not the content of the commit. You could commit some
code then I. Then I squash my commits into yours and use your commit
message. You could also include the previous commit hash in your commit
message.
But correct me if I am wrong, but that would be difficult (if not
impossible) to verify once you get into merging code since the patch can be
merged in at another point in history entirely.. and still doesn't work
because I can still squash commits into yours. I don't see how it can work
at all unless I am missing something obvious (which I fear I may be?).
I also don't believe Linus is talking just from the perspective of how the
kernel project works. The integrity of a git repository is maintained by
the hash chaining and by the distributed nature of the repository. If
someone hacked github and changed the history of the tree, the next time
you tried to push his code up it would fail because the history had changed
- tampering is immediately obvious in git.
Regards,
Drak
On 19 December 2013 17:44, Peter Todd <pete at petertodd.org> wrote:
> On Thu, Dec 19, 2013 at 04:04:17PM -0000, Amir Taaki wrote:
>
> Looks like for this to actually go to the email lists they need to be in
> the To: field.
>
> > About signing each commit, Linus advises against it:
> >
> >
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> >
> > "Btw, there's a final reason, and probably the really real one. Signing
> > each commit is totally stupid. It just means that you automate it, and
> you
> > make the signature worth less. It also doesn't add any real value, since
> > the way the git DAG-chain of SHA1's work, you only ever need _one_
> > signature to make all the commits reachable from that one be effectively
> > covered by that one. So signing each commit is simply missing the point."
> >
> > What do you reckon?
>
> His point is valid, but it's valid in the context of how Linux
> development is done, not Bitcoin. The key difference being that Linus
> and other kernel developers have a model where code is passed around on
> mailing lists and between developers rather than stored on untrustworthy
> third-parties like github.
>
> For instance typically someone will submit a patch to the kernel
> development mailing list, example:
> http://www.mail-archive.com/[email protected]/msg558841.html
> That patch isn't signed, and the email itself doesn't have to be PGP
> signed either. However a trusted maintainer of the relevant subsystem
> will (in theory) look over the patch carefully and commit it to their
> personal tree on a secure computer. (in theory)
>
> At some point the maintainer will create a *signed* tag on a commit with
> one or more patches, often many patches, another another maintainer
> higher in the hierarchy (maybe even Linus) will *merge* that tag into
> their tree, hopefully checking the signature first! Modern versions of
> git actually include the tag signature in the merge commit, so the
> result is signed by the original maintainer; note how this contradicts
> Linus's email with regard to the idea of separable signatures.
> Eventually multiple such groups of patches build up and the result is
> tagged as a release, and that release tag is signed.
>
> Accountability in this model rests with maintainers, and source-code
> stays on a multitude of personal, secure, locations. (in theory)
>
>
> However since we like to use github and tend to get code directly from
> it our main risk is github (or similar) being compromised. Given that I
> think we're much better off using per-commit signatures, and in effect
> continually making the statement "Yes, this commit/merge was really
> produced by me on my machine, although I may have made a mistake and
> might not have looked at the code as thoroughly as I maybe should have."
> The statement *is* weaker than Linus's model of "This signature is
> Really Official and Stuff and I've carefully checked everything." but I
> think we're much more interested in getting a strong guarantee on who
> made the commit than some strong statement about its actual contents -
> humans are fallible anyway.
>
> > Also do you approve of the other link I sent you?
> >
> > https://wiki.unsystem.net/index.php/DarkWallet/Negotiation
>
> I think you're conflating identities with the messaging layer; focus on
> the latter and use off-the-shelf identity systems like OpenPGP and SSL
> certificate authorities. Remember that every new identity system that
> gets involved is another way for an attacker to MITM attack you; you're
> better off using whatever the user is using already.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000016a442255c6d15cd6e085991c1efffc9caeff5fc6da14368a
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131219/fff6022f/attachment.html>

2023-06-07 17:10:47

- reply

📅 Original date posted:2013-12-16
📝 Original message:Jim,
It's great to see the many ways wallet authors try to protect users from
easy to make mistakes, especially against losing funds.
But this issues isn't confined to custom transaction - some wallet
implementations have a fee field and almost all wallets allow the fee rate
to be configured in preferences. Sanity checking is sensible where a user
can override the calculated fee. Some wallets don't allow the fee to be
adjusted at all, but quite a few do.
Drak
On 16 December 2013 10:46, Jim <jim618 at fastmail.co.uk> wrote:
> Yes I saw that on reddit too.
>
> I think it applies mainly to custom transactions rather
> than where fees are calculated automatically.
>
> Another variant of not understanding change that loses
> people's bitcoins I have encountered is:
> 1) Import a private key of a brainwallet/ paper wallet.
> 2) Send a small amount of bitcoin from that key.
> 3) The user then secure deletes all copies of the wallet
> 'for security'. If they are not careful they can delete
> a change address with funds on it.
>
> In MultiBit I have tried to reduce this possibility by:
> 1) Hiding the ability to delete wallet (in the next version
> I am removing it entirely)
> 2) There is always a single key in a new wallet. When
> a user imports a key then that makes two. I always send
> the change to the second address, if it is available.
> (This is bad for privacy but at least lessens the chances
> that the funds become lost).
>
> If users are determined to use a brain wallet and
> secure delete every copy of the wallet after they use
> them you cannot stop them (it is their machine after all)
> But these two options help lessen the chance of bitcoin
> loss if they do.
>
> For the HD version of MultiBit we are removing the import
> of individual private keys entirely and only supporting HD
> addresses, primarily for safety reasons.
>
> Jim
>
> On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote:
> > Not sure if this is the right place, but since a few wallet authors
> > congregate here I though it might be the best place.
> >
> > It seems every once in a while you see stories of people accidentally
> > paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
> > 0.05 BTC transaction[1], oops. There was another recently where someone
> > paid a fee of about 200BTC which fortunately the pool operator refunded.
> >
> > It just occurs to me this kind of sad story could be averted if wallets
> > implemented a confirmation box if the fee amount seems crazy - for
> example,
> > if it's >10x what the default fee should be, or if it's greater than x%
> of
> > the sending amount. "the fee seems unusually high, are you really sure
> you
> > want to pay X in fees?"
> >
> > I realise the exact details of this might need to be fleshed out given we
> > want flexible fees, but it should be pretty simple to agree with what
> looks
> > like an unusually large fee according to the going rate.
> >
> > Drak
> >
> > [1]
> >
> http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
> >
> ------------------------------------------------------------------------------
> > 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
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> ------------------------------------------------------------------------------
> 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/20131216/a379b0a4/attachment.html>

2023-06-07 17:10:46

- reply

📅 Original date posted:2013-12-16
📝 Original message:Not sure if this is the right place, but since a few wallet authors
congregate here I though it might be the best place.
It seems every once in a while you see stories of people accidentally
paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
0.05 BTC transaction[1], oops. There was another recently where someone
paid a fee of about 200BTC which fortunately the pool operator refunded.
It just occurs to me this kind of sad story could be averted if wallets
implemented a confirmation box if the fee amount seems crazy - for example,
if it's >10x what the default fee should be, or if it's greater than x% of
the sending amount. "the fee seems unusually high, are you really sure you
want to pay X in fees?"
I realise the exact details of this might need to be fleshed out given we
want flexible fees, but it should be pretty simple to agree with what looks
like an unusually large fee according to the going rate.
Drak
[1]
http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131216/b82d03e2/attachment.html>

2023-06-07 17:10:31

- reply

📅 Original date posted:2013-12-08
📝 Original message:On 8 December 2013 20:50, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Sadly this isn't true: There are (many) CAs which will issue a
> certificate (apparently sometime within minutes, though last
> certificate I obtained took a couple hours total) to anyone who can
> respond to http (not https) requests on behalf of the domain from the
> perspective of the CA.
>
Simple verification relies on being able to answer the email sent to the
person in the whois records, or standard admin/webmaster@ addresses to
prove ownership of the domain. This is a good point to note -
bitcoin.orgshould not get a simple certificate, but one that requires
identify
verification for the person/org who is applying. They are more expensive.
> This means you can MITM the site, pass all traffic through except the
> HTTP request from the CA, and start intercepting once the CA has
> signed your certificate. This works because the CA does nothing to
> verify identity except check that the requester can control the site.
>
> If you'd like to me to demonstrate this attack for you I'd be willing—
> I can provide a proxy that passes on :80 and :443, run your traffic
> through it and I'll get a cert with your domain name.
>
You cannot MITM SSL connections - it will cause a browser warning.
I do not have the means, but it has been demonstrated some people are
performing BGP redirections, daily, and on a massive scale... and it's a
problem, because BGP was designed on implicit trust.
> I'm sorry for the tangent here— I think this sub-discussion is really
> unrelated to having Bitcoin.org behind SSL— but "someone is wrong on
> the internet", and its important to know that SSL hardly does anything
> to reduce the need to check the offline signatures on the binaries.
You are right that the CA system is not full-proof, one CA was caught
issuing a bogus certificate on purpose a while back, I forgot the name but
it resulted in CA certificate revokation and the entire company being
blacklisted from Firefox and Google Chrome forever - basically a summary
corporate execution. I personally imagine the CIA or other state actor
could just quietly buy up an already trusted CA and abuse them. But it's
clear, people are watching, and if a CA is caught once, that's the end of
their business forever: Firefox and Google demonstrated that. The strategy
is possibly too expensive and risky to carry off which is maybe why they
don't do it.
What has been noted with all the Snowden leaks, and with the Lavabit case,
the security agencies did not get bogus certificates issued, they still got
court orders, or other deception to get hold of the encryption certificates
of their targets instead of issuing their own so they could listen in.
The CA system is not full proof, but it is what we have. Similar arguments
have been made against the use of identity certificates for bitcoin, but
that hasnt stopped it's inclusion in the bitcoin payment protocol.
Anyway, I take your points, but this is an area I am quite passionate about
so it's important for me to be clear.
Regards,
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/875bc5d8/attachment.html>

2023-06-07 17:10:26

- reply

📅 Original date posted:2013-12-08
📝 Original message:On 8 December 2013 20:40, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
> > Right now I think Sirius still owns DNS for bitcoin.org which is
> nonsense.
> > He needs to pass it on to someone who is actually still involved with the
> > project. Again, the most obvious neutral candidate would be the
> Foundation.
>
> I am opposed to Bitcoin Foundation having control of Bitcoin.org, and
> I think it would be foolish of the foundation to accept it were it
> offered.
>
What do you suggest though? We will need to trust someone (even in a group
each person can act autonomously).
The only thing I can suggest would be to hand the keys to the bitcoin
project lead.
Otherwise, who has admin rights to the code projects
(github/sourceforge/this mailing list)? Those people have proven they can
be trusted so far.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/7513277a/attachment.html>

2023-06-07 17:10:26

- reply

📅 Original date posted:2013-12-08
📝 Original message:On 8 December 2013 21:01, Luke-Jr <luke at dashjr.org> wrote:
> On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> > Otherwise, who has admin rights to the code projects
> > (github/sourceforge/this mailing list)? Those people have proven they can
> > be trusted so far.
>
> Can someone explain how Sirius has proven the least bit untrustworthy?
It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to pickup
and run with it. The control over the domain (including ability to renew
registration, alter nameservers) needs to be with more than one person.
That's why I suggest using the same people who have control over the
software project at sf,github.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/232210d7/attachment.html>

2023-06-07 17:10:25

- reply

📅 Original date posted:2013-12-08
📝 Original message:On 8 December 2013 12:37, Luke-Jr <luke at dashjr.org> wrote:
> Encryption is useless here. We want everyone to be able to download Bitcoin
> clients. Binaries on sourceforge are signed by multiple parties using
> gitian.
>
> > Decentralization:
> > So long as we actually use DNS, the website is centralized :( However,
> > its content isn't (can be forked on GitHub), but regarding the domain
> > name, there is not much we can do against this AFAIK.
>
> So long as someone has root (or a user that can modify it), the website is
> centralised. To really solve this, we would need a dedicated server that
> accepts commands only when signed by N-of-M parties, inside a cage locked
> by
> padlocks with keys held by independent parties, with a SSL certificate
> issued
> by an authority that has multiple parties watch it every step of the way
> into
> that server.
Malicious actors with root access to the server is another issue entirely.
Sure it's a problem, but it is not an argument not to have a properly
signed SSL certificate.
With out one, the exploit can be performed on routers to redirect traffic
through a third party alter the content of the site (like the links on
bitcoin.org to various wallet projects) and then onto the correct
destination. SSL at least mitigates that. For example it would be trivial
to impersonate Electrum's site or whatever, "change" the link on the fly
that appears on the trusted source bitcoin.org via BGP redirection. Now
users will be directed to the scammers site which could be identical except
for domain name and of course malicious binaries.
BGP redirection is a reality and can be exploited without much
expense/effort. MITM is a real world threat, not some theoretical
possibility - reports show it's happening on an unprecedented scale. SSL is
essential - that's a no-brainer. Sure other measures are important, but
without SSL there is almost no point to any of the other options.
SSL is so considered so important that the *HTTP 2.0 spec might be SSL
only*according to recent discussions at the W3C (
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html).
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/c6778642/attachment.html>

2023-06-07 17:10:15

- reply

📅 Original date posted:2013-12-03
📝 Original message:On 3 December 2013 11:03, Peter Todd <pete at petertodd.org> wrote:
> UI once both are implemented is to not show anything in the default
> case, and explain to the user why they have to pay extra in the unusual
> case where they are spending a whole bunch of dust.
Yes, that's the other problem with a merchant setting a fee - they have no
idea how large the transaction might be. If you spend a bunch of dust the
fee could be 2 or 3x the expected fee. Then you might get merchants
including higher fees by default to account for this. That means we end up
paying more per kb over time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/199e85e4/attachment.html>

2023-06-07 17:10:10

- reply

📅 Original date posted:2013-12-03
📝 Original message:On 3 December 2013 11:46, Mike Hearn <mike at plan99.net> wrote:
> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
>>
>> If users want to pay with a huge transaction then it seems to me the user
>> should cover that cost. Allowing users to pay merchants with 100K
>> transactions full of dust and expecting them to eat the cost seems like a
>> great way to enable bleed-the-merchant-dry attacks.
>>
>
> A merchant can always refuse the payment and refund it if that's a
> practical problem. I doubt it would be though. If a user is trying to buy
> something from the merchant, they will want it to work, and it'll be up to
> the developers of the wallet they're using to ensure it never does anything
> obnoxious or unacceptable that would result in people hating to receive
> money from that app.
>
Refunds in this circumstance would be problematic because someone is going
to lose because they have to pay the fee. If the sender's money is refunded
minus the fee, they will be unhappy. And the merchant will be unhappy about
having had an unacceptable transaction they have to send back, and eat a
fee for the privilege.
This kind of situation needs to be avoided at all costs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/85ad8acd/attachment.html>

2023-06-07 17:09:42

- reply

📅 Original date posted:2013-11-14
📝 Original message:Given the meteoric growth many are now saying we should just switch
straight to Satoshi (uBTC) because it looks like we will be seeing BTC
valued in the thousands pretty soon. Small decimal numbers are certainly
not very attractive to the masses. There's no point switching to mBTC only
to have to switch to uBTC later - especially when that later could be a lot
sooner.
Unless something is recommended/done by the bitcoin core developers I doubt
much will change at bitcoin user/consumer level.
Drak
On 14 November 2013 11: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?
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131114/2209c344/attachment.html>

2023-06-07 17:09:37

- reply

📅 Original date posted:2013-11-15
📝 Original message:On 16 November 2013 01:10, Luke-Jr <luke at dashjr.org> wrote:
> On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
> > So "a payment clears after one confirmation, but you might want to wait
> > until the payment has been confirmed n times".
> > Then at least you are not using the same word for two different meanings
> > and you're using stuff more familiar in popular lexicon.
> > I dont think it's helpful for users if we use the word "blocks".
>
> "Confirmations" in a numeric context isn't correct, though. We're using to
> it
> because we've been using Bitcoin so long, but to the average person they
> would
> expect it to mean something more than it is. If not referring to blocks,
> then
> perhaps "witnessed N times"?
If you are talking about user interface, I don't think you have to be
technically correct. It must make sense to the user.
A user cares about his balance, and did a payment "go through", and "did my
payment arrive/clear".
The UI is for their benefit.
> > For years, people had a problem with "email address", instead using
> "email
> > number" but they got there eventually. Most people nowadays use "email
> > address"
> > So "payment address" or "bitcoin address" make better sense here when
> > qualified as a "<foo> address" and not just an "address"
> >
> > You could also call it "payment id", but I dont think "invoice id" since
> > no-one pays to an invoice id that's just a reference for a payment, not
> the
> > destination.
> >
> > People are very familiar with Paypal these days, and are familiar with
> > "paypal address" or their "paypal id" so again I think valid contenders
> are
> > "bitcoin address" or "bitcoin id".
>
> I think you might be demonstrating my point with regard to user confusion
> here. Bitcoin addresses are *not* like email addresses, paypal ids, etc.
> Bitcoin addresses aren't the destination - they're point to a destination
> (an
> account in a wallet), but they also represent information such as who is
> paying and what for - in other words, a specific invoice.
Maybe, but again from the user's perspective they pay someone, and they
receive money - just like you do with paypal using an email address.
The technical bits in the middle dont matter to the user and trying to crap
stuff in to be technically correct is just confusing to them.
The UI needs to be about the user and fit with his experience of the world.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131116/49a7ee31/attachment.html>