Amir Taaki [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-17 to 2021-04-28
💬 Posted a total of 110 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP 15, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 10:22:05

- reply

📅 Original date posted:2012-07-09
📝 Original message:By that time in the future, when there are many clients, there should just be a flat list or no list at all.
----- Original Message -----
From: Nils Schneider <nils at nilsschneider.net>
To: bitcoin-development at lists.sourceforge.net
Cc:
Sent: Monday, July 9, 2012 6:33 PM
Subject: Re: [Bitcoin-development] Random order for clients page
I don't think that's a good idea as it can easily confuse or annoy users
when things move around. The ordering should be preserved as much as
possible so users can remember where they found a client they liked
(e.g. 2nd row, 1st column and screenshot with light and blue colors).
Making them search the entire page is inefficient and will just get
worse once there are many clients on the page (and I think that's the goal).
On 09.07.2012 17:54, Amir Taaki wrote:
> Took me a while, but finally got it working.
>
> Entries on the clients page are randomly ordered when the page is generated.
>
> https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03
>
> We should regenerate the page every 2 days. This gives fair exposure to all the clients listed.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:06:41

- reply

📅 Original date posted:2012-05-02
📝 Original message:This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable).
If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details:
http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
You suggest creating something new for your hackerspace, like a
bikeshed. But now all anyone will discuss is its colour. No bikeshed
will be built.
Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum.
________________________________
From: Gary Rowe <g.rowe at froot.co.uk>
To: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Wednesday, May 2, 2012 8:34 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page
How about keeping it simple?
Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org
MultiBit
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use
* Available for Windows, Mac, Linux with installer
* Developed in Java
* Website: http://multibit.org
Armory
* Requires the entire blockchain
* Dependent client of Bitcoin-Qt
* Designed for occasional use
* Available for Windows (64-bit only), Mac, Linux (self-build)
* Developed in Python
* Website: http://bitcoinarmory.com/
Electrum
* Requires no blockchain
* Dependent client of Bitcoin-Qt (on server)
* Designed for occasional use
* Available for Windows, Linux (self-build)
* Developed in Python
* Website: http://ecdsa.org/electrum/
Bitcoin Wallet (Android client)
* Requires a reduced blockchain
* Standalone client
* Designed for occasional use on mobile
* Available for Android only
* Developed in Java
* Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
>
>On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
>
>Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
>
>
>
>
>----- Original Message -----
>From: Jeff Garzik <jgarzik at exmulti.com>
>To: grarpamp <grarpamp at gmail.com>
>Cc: bitcoin-development at lists.sourceforge.net
>Sent: Wednesday, May 2, 2012 7:29 PM
>Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
>On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>>> Try "Reply to All"
>>
>> That puts the sender in 'to' and list in 'cc',
>> which dupes to the sender and eventually
>> blows out the to and cc lines as everyone
>> chimes in and doesn't trim. 'reply to' solves
>> most of that. assuming the list sw can do it.
>
>"Reply-To" Munging Considered Harmful
>http://www.unicom.com/pw/reply-to-harmful.html
>
>
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgarzik at exmulti.com
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 10:06:24

- reply

📅 Original date posted:2012-05-02
📝 Original message:This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in.
On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send.
Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again.
----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: grarpamp <grarpamp at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Wednesday, May 2, 2012 7:29 PM
Subject: Re: [Bitcoin-development] new bitcoin.org clients page
On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> Try "Reply to All"
>
> That puts the sender in 'to' and list in 'cc',
> which dupes to the sender and eventually
> blows out the to and cc lines as everyone
> chimes in and doesn't trim. 'reply to' solves
> most of that. assuming the list sw can do it.
"Reply-To" Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 03:01:28

- reply

📅 Original date posted:2012-01-31
📝 Original message:BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage).
Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21.
I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO).
Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world!
(no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :)

2023-06-07 02:56:11

- reply

📅 Original date posted:2012-01-16
📝 Original message:Bunk argument. This is an issue that affects bitcoin directly.
Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote.
http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action
The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia.
It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad.
----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Amir Taaki <zgenjix at yahoo.com>
Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net>
Sent: Sunday, January 15, 2012 10:37 PM
Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> How is this not the most important world issue right now?
>
> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>
> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
There are always issues that raise ire and moral outrage. I would
rather that bitcoin.org stay apolitical -- our users will appreciate
this in the long run.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 02:55:52

- reply

📅 Original date posted:2012-01-15
📝 Original message:How is this not the most important world issue right now?
EVERYTHING is under threat. Go nuclear to show our nerd-rage.
Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.

2023-06-07 02:43:39

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Professional summarizer skeptical of IBAN's usefulness in Bitcoin. Believes legacy banking systems are inefficient and built by finance people, not engineers. Supports easy-to-implement aliases.
📝 Original message:I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess.
The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0.
I don't even mind the maxim "take everything the banks have done and do the complete opposite" :)
I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations.
These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO.
I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives.
________________________________
From: slush <slush at centrum.cz>
To: Khalahan <khal at dot-bit.org>
Cc: bitcoin-development at lists.sourceforge.net
Sent: Friday, December 16, 2011 7:54 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.
For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...
Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.
Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.
slush
On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal at dot-bit.org> wrote:
>Namecoin is a peer-to-peer generic name/value datastore system.
>Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.
>
>
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
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/20111216/6566d3c1/attachment.html>

2023-06-07 02:43:19

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Bitcoin developers discuss reusing code for IP transactions to enable dynamic address lookup and mitigate security flaws, with minimal protocol extension.
📝 Original message:This is maybe the best idea. I added it:
https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions
Things I like about this:
- IP transactions are useful, but have a security flaw. This mitigates their security problems.
- The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat.
I feel that for any protocol extension, less is more. The less code
needed, the better the extension. Not always but generally we want to
avoid bitcoin protocol bloat which *will* happen far in the future. The
only way to mitigate how spaghettified the standard will be in the
future, is by careful cautious planning now.
- We can have a proxy node running 24/7 for us, serving our public keys in lieu of us.
________________________________
From: theymos <theymos at mm.st>
To: bitcoin-development at lists.sourceforge.net
Sent: Thursday, December 15, 2011 7:59 PM
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user at server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
public key
- Extend "checkorder" messages so they can specify an account to
send BTC to. Or standardize on how to put the account into the
message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
also be used here to avoid having to use the IP transaction protocol
sometimes. The public key for signing "reply" messages can be gotten
from TXT records. This will be safe with DNSSEC and Namecoin. With
plain DNS Bitcoin could take a SSH-like approach and ask the user to
verify the public key the first time it is used, remembering it later.
DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.
------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
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/20111215/ea93e7ce/attachment.html>

2023-06-07 02:36:48

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Satoshi proposes locking version numbers to protocol version and using sub_version_num field + revision number for individual builds to avoid version bumping.
📝 Original message:Hey,
Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds?
Satoshi 0.4
BitcoinJava 120311
bitcoin-js 6
Like so. Otherwise we will have version bumping insanity :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/bf315b92/attachment.html>

2023-06-07 02:36:03

- reply

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Request for help to contact MT to bring it back online as the BIPs are not yet copy-edited and a new one needs to be added.
📝 Original message:Anybody know how to contact MT about getting it back online? I still haven't finished copy-editing the BIPs and need access to them since there's a new one to be added.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111027/6dfec4cd/attachment.html>