<unnamed>

Public Key

npub12rkw0jajmsck4uwdtksdvtswrlkypusfryjzera7m4fhqta6jhdsz3aqxc

Profile Code

nprofile1qqs9pm88ewedcvt278x4mgxk9c8plmzq7gy3jfpv37ld65ms97aftkcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mq3lvl8y

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:25:32 CEST

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

- 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:19:32 CEST

- 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:15:38 CEST

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

- reply

📅 Original date posted:2014-03-11
📝 Original message:Gavin,
You have pretty much nailed my intent in both respects. This sets up a way
to negotiate the address and abstract away the nasty details of finding
public keys from bitcoin addresses, and provides a nice clean way for
redemption abstracting away the long strings of hex.
For redemption, I think as each party signs the tx if the script returns
true, it would be acceptable to just go right ahead and broadcast it, or
maybe as you suggest all signatures go back to the initiating party and
they do the final work.
I very much like the idea of assuming each party uses HD wallets, that
certainly simplifies things greatly. I also like the use of email addresses
as a negotiation medium, but I also wonder if this could be made agnostic
in any BIP proposal so it could work with other communication mediums like
bitmessage for example (just forward thinking anonymity a little).
I definitely think there is a need for a protocol because multisig,
regardless of the application has two technically involved steps:
negotiation of an address, and redemption of any subsequently encumbered
funds. A protocol would enable different wallet implementations to
participate in such a transaction and make wide-spread use much more likely
and possible.
Drak
On 11 March 2014 01:15, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Multisig is orthogonal to the payment protocol (but payment protocol is
> needed first).
>
> There need to be protocols for:
>
> a) Establishing multisig wallets of various sorts. See:
> https://moqups.com/gavinandresen/no8mzUDB/
> https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0
> ... etc. for a UI mock-up.
> There needs to be some protocol so all participants in a multisig wallet
> contribute keys (actually, we should just assume everybody uses BIP32 HD
> public keys so we get privacy from the start).
>
> Multi-person shared wallets, escrows, and "wallet protection service"
> wallets (which might be protected with two-factor authentication) are
> different use cases and probably use slightly different protocols (and will
> probably need different BIPs eventually).
>
>
> b) Gathering signatures for a multisig spend. Here is where the payment
> protocol is useful; the PaymentRequest message should be passed around so
> all participants know what is being paid for, and maybe a partially-signed
> Payment message is where the signatures are gathered (or maybe the
> signatures are sent separately and one of the participants creates and
> submits the Payment and gets the PaymentACK... "to be designed").
> See:
> https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96
> https://moqups.com/gavinandresen/no8mzUDB/p:af7339204
> ... for UI mock-up for the multi-person-spend case.
>
> And maybe a protocol for "I don't want to be part of this multisig any
> more / I lost control of my private key don't trust me in this multisig any
> more".
>
>
>
> On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> All of that only melds with the payment protocol under an extremely
>> expansive definition of "payment." The payment protocol is really
>> geared towards a direct one-to-one relationship....
>
>
>
>>
>>
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> 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/20140311/5b55c4d3/attachment.html>

2023-06-07 17:15:01 CEST

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

- 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:33 CEST

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

- reply

📅 Original date posted:2014-01-13
📝 Original message:On 13 January 2014 19:40, Roy Badami <roy at gnomon.org.uk> wrote:
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
My thoughts exactly.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140113/488b025d/attachment.html>

2023-06-07 17:11:47 CEST

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

- reply

📅 Original date posted:2014-01-17
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/e2b36d03/attachment.html>

2023-06-07 17:10:47 CEST

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

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

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

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

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

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

- reply

📅 Original date posted:2013-12-09
📝 Original message:On 9 December 2013 15:35, Wladimir <laanwj at gmail.com> wrote:
>
> On Mon, Dec 9, 2013 at 4:19 PM, Drak <drak at zikula.org> wrote:
>
>>
>> IMO, to avoid that, no files should be placed online unless they are the
>> official release.
>>
>
> They *are* the official release as soon as they're uploaded. We may wait
> for some extra gitian builds to be more confident and make the announcement
> on the forums and such, but the downloads themselves don't change anymore.
>
That is exactly the point and the moment they are publicly available you
cannot stop people talking about it or noticing it, or posting official
looking sticky posts at bitcointalk like this one:
https://bitcointalk.org/index.php?topic=364353.0. Was that an official
announcement?
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/9be62b4a/attachment.html>

2023-06-07 17:10:21 CEST

- reply

📅 Original date posted:2013-12-09
📝 Original message:On 9 December 2013 13:52, Roy Badami <roy at gnomon.org.uk> wrote:
>
> On Mon, Dec 09, 2013 at 01:39:51PM +0000, Drak wrote:
> > Someone needs to update the bitcoin.org website, it still points
> downloads
> > to 0.8.5
>
> Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
> announcement? I think it makes sense that release candidates are not
> promoted on bitcoin.org.
It was released and it's all over bitcointalk/reddit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/3926b3fb/attachment.html>

2023-06-07 17:10:21 CEST

- reply

📅 Original date posted:2013-12-09
📝 Original message:On 9 December 2013 15:07, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Dec 9, 2013 at 6:55 AM, Drak <drak at zikula.org> wrote:
> > It was released and it's all over bitcointalk/reddit
>
> It has not been released. It's queued for announcement. We were
> waiting for another independant gitian build before sending out the
> announcement.
>
Why would it be made available for download at sourceforge.net if it's not
actually released? The files are available here:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.6/ and
people watch the sf rss feeds etc...
Seems to me like there needs to be a better release workflow. As far as the
world is concerned, they are downloading the 0.8.6 and there is a lot of
community buzz about it already.
IMO, to avoid that, no files should be placed online unless they are the
official release.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/507c1713/attachment.html>

2023-06-07 17:10:20 CEST

- reply

📅 Original date posted:2013-12-09
📝 Original message:Someone needs to update the bitcoin.org website, it still points downloads
to 0.8.5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/6891ac5b/attachment.html>

2023-06-07 17:10:10 CEST

- 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:10:08 CEST

- reply

📅 Original date posted:2013-12-03
📝 Original message:On 3 December 2013 10:45, Mike Hearn <mike at plan99.net> wrote:
> On Tue, Dec 3, 2013 at 11:36 AM, Drak <drak at zikula.org> wrote:
>
>> I dont like the idea of putting the min fee in the hands of the receiver.
>> Seems like that will work against the best interests of senders in the long
>> run.
>>
>
> Senders have no interest in ever attaching any kind of fee, which is one
> reason we explored child-pays-for-parent for a while. It's not the sender
> who cares about double spending risk. Left to their own devices, all
> senders would always attach no fee at all (or rather: whatever the min was
> to get the transaction relayed to the merchant).
>
I respectfully disagree. Senders need their funds to be received. The
incentive is right there. Miners want mining fees. So if you want to pay
for something, you need to make sure payment arrives. Senders know that if
they exclude the fee it might not arrive at all. Miners increasingly ignore
no or low fees. So those two agents together ensure there is a fee more
than not. If what you said was true, we would hardly see fees being paid at
all, but on the contrary we see lots of fees, and much higher than the
minimum 0.0001/kb rate that is currently required.
Merchants will just include ridiculous fees - there are some exchanges that
do it already - MtGox being the famous example requires a 0.001 fee 10x
higher than the network rate - the CEO does it because he says "it's
better". That's not a fee going to MtGox, that is the miner fee and they
have no plans to reduce it.
Typically vendor software may not get updated and or lag behind with fat
fees never decreasing or decreasing way too slowly - it's just not fluid or
dynamic enough when it rests with the vendor.
However, receivers do want a fee attached,
>
No - receivers want to be paid. If they are not paid they wont dispatch the
goods or service. Neither party is happy in that circumstance. The
incentive that the payment confirms is there naturally.
> That's what fee estimation does, essentially, minus the encoding into
> blocks. Once you start getting miners telling people what fees are directly
> you run into cases where they might try to lie about their behaviour or
> otherwise influence the average. Querying all nodes avoids that problem.
>
Miners cant lie about fees accepted because that's part of the transaction.
When Alice sends funds to Bob it includes the fee information and that is
included in the block. There is no way to fake it. The average fee paid is
provable - so there is no need to query nodes at all, you simply look at
the blockchain. You dont even need to write it into the blockchain since it
can be calculated from the blockchain, it would just make it simpler.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/55522461/attachment.html>

2023-06-07 17:10:07 CEST

- reply

📅 Original date posted:2013-12-03
📝 Original message:I dont like the idea of putting the min fee in the hands of the receiver.
Seems like that will work against the best interests of senders in the long
run.
Why not try a different path of calculating the min fee like difficulty
retarget. You can analyse the last 2016 blocks to find the average fee
accepted per kb (which would include transactions that were included
without fees) and then write that into the block as a soft recommendation
that wallets could use in the UI. This way the price can vary up and down
according to what people were willing to spend on fees and miners willing
to accept.
I absolutely do not trust vendors to set fees. I think it has to be based
on what senders are willing to pay and what miners are willing to accept.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/17a85798/attachment.html>

2023-06-07 17:09:48 CEST

- reply

📅 Original date posted:2013-11-19
📝 Original message:On 19 November 2013 17:01, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Nov 19, 2013 at 8:53 AM, Drak <drak at zikula.org> wrote:
> > It's quite normal for standards bodies to allocate numbers when in draft
> > status. If they don't pass, they don't pass - they are clearly labelled
> > DRAFTs.
> >
> > +1 on having things in a github repository. Much better for
> collaboration,
>
> The IETF makes a clear distinction between individual proposals and
> documents which have been accepted by a working group. The former are
> named after their authors. Work is not assigned a number until it is
> complete.
>
> I believe it is important to distinguish complete work that people
> should be implementing from things which are incomplete, and even
> more important to distinguish the work of single parties.
>
> Otherwise you're going to get crap like BIP90: "Increase the supply of
> Bitcoins to 210 million" being confused as an earnest proposal
> supported by many that has traction.
>
I wasnt suggesting people add drafts willy nilly to the repository.
When working on a proposal you can work on it in your own fork and create a
PR. When it's ready to be accepted as a working draft by the WG, then it
can be merged into the draft folder. At which point, PRs are made to that
draft copy until it gets into a ready state to become final. If passed,
it's moved to the accepted/ folder.
This way random BIPS cannot be added to the drafts/ folder in the official
repo. They are only added once they are accepted as a working draft
proposal by Gavin or whatever. Now you get all the niceties of github
workflow for collaboration and tweaking of the draft proposal.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131119/ca9c1e2a/attachment.html>

2023-06-07 17:09:48 CEST

- reply

📅 Original date posted:2013-11-19
📝 Original message:On 19 November 2013 16:32, Wladimir <laanwj at gmail.com> wrote:
>
> On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
>> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
>> are not automatically assigned a BIPS number.
>>
>
> Are we going to move ahead with this?
>
> If so, I'm volunteering to create the repository and import the current
> BIPs from the wiki there (and convert from wiki markup to markdown where
> necessary).
>
> 2) Time passes. Software for BIP drafts is developed, tested,
>> published, and publicly discussed in a typical open source manner.
>>
>
> Personally I think it is useful to have a number as soon as a BIP can be
> implemented, even if still in draft status; it gives something to refer to
> when mentioning a certain improvement proposal (in commit messages and such
> it could be called BIP xxx Draft).
> I don't think we are at risk of running out of numbers to assign any time
> soon.
>
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - they are clearly labelled
DRAFTs.
+1 on having things in a github repository. Much better for collaboration,
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131119/54f8eeca/attachment.html>

2023-06-07 17:09:37 CEST

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

2023-06-07 17:09:35 CEST

- reply

📅 Original date posted:2013-11-15
📝 Original message:On 14 November 2013 23:01, Luke-Jr <luke at dashjr.org> wrote:
> I wonder if it might make sense to bundle some other terminology fixups at
> the
> same time.
>
A very good idea.
> Right now, Bitcoin-Qt has been using the term "confirmations" (plural) to
> refer to how many blocks deep a transaction is buried. We also use the term
> "confirmation" to refer to the point where a transaction is accepted as
> paid.
> IMO, the latter use makes sense, but the former leads to confusion
> especially
> in light of scamcoins which abuse this confusion to claim they have "faster
> confirmations", implying that the actual confirmation occurs faster when it
> really doesn't. "5 blocks deep" may not be more clear to laymen, but at
> least
> it makes it harder for people to confuse with actual confirmation.
>
I think people are more familiar with check clearance - "the payment/check
has cleared".
If "confirmation" and "n confirmations" together are problematic, I'd talk
about "cleared payments" and "n confirmations"
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".
Without the technical details, I just explain to normal bitcoin users that
the Bitcoin network checks and confirms the payment is valid (multiple
times).
I think we all know the problems with the term "address". People naturally
> compare it to postal addresses, email addresses, etc, which operate
> fundamentally different. I suggest that we switch to using "invoice id" to
> refer to what is now known as addresses, as that seems to get the more
> natural
> understanding to people. On the other hand, with the advent of the payment
> protocol, perhaps address/invoice id use will die out soon?
>
I think "key id" is a bit alien at user level - it's not something they are
used to.
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".
Regards,
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131116/4c212074/attachment.html>