Bitcoin Forum
June 21, 2024, 06:23:52 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 »
1  Bitcoin / Meetups / Orange County Bitcoin Meetup on: August 10, 2017, 09:43:12 AM
Any Bitcoiners in the area, feel free to stop by.  

Tuesday(8/15) 6:00pm

5151 California Ave, Irvine, CA 92617

https://www.meetup.com/OC-Bitcoiners/events/242391421/
2  Alternate cryptocurrencies / Service Discussion (Altcoins) / Re: Can i trust EtherDelta with my Private Keys ? on: July 27, 2017, 12:40:41 PM
Yes, you can trust any such outfit with your privkeys - insofar as your personal 'sorry for your loss' threshold allows
3  Bitcoin / Meetups / Orange County Bitcoin Meetup Tuesday(7/25) on: July 22, 2017, 01:18:32 PM
Any Bitcoiners in the area, feel free to stop by.   

Tuesday(7/25) 6:30pm

120 Newport Center Drive, Newport Beach, CA

https://www.meetup.com/OC-Bitcoiners/events/241736310/
4  Bitcoin / Bitcoin Discussion / Re: [ANN] THE Bitcoin Foundation - Incorporated on: November 07, 2014, 10:37:55 AM
Full story published on Qntra:
http://qntra.net/2014/11/introducing-a-new-bitcoin-foundation/
5  Bitcoin / Bitcoin Discussion / Re: [ANN] THE Bitcoin Foundation - Incorporated on: November 06, 2014, 12:01:56 PM
Are you serious about this?

yea - these guys are deadly serious.

i would argue they are quite a bit more 'serious' than the other bitcoin [muppet] foundation

6  Bitcoin / Bitcoin Discussion / [ANN] THE Bitcoin Foundation - Incorporated on: November 05, 2014, 01:59:09 PM
Preceded by Mr. Vulpes' thoughtful perlustration on the current state of bitcoin bloat, the raucous #b-a crew set sail for warmer waters.

The (regrettably named) Bitcoin Foundation was coronated in exiguous ceremony, as with many great things borne in #b-a.  There's already quite a bit of progress to date.  It should be interesting to see how this develops and if the de-crufted bitcoin core gains popularity within the mining community.

set your rigs to downgrade @ http://thebitcoin.foundation/


From Trilema:
"The Bitcoin Foundationi was incorporated on #bitcoin-assets last week. Here’s a section of its charter :

[0×1] BACKGROUND ; SCOPE ; OBJECTIVES

Bitcoin is a far reaching innovation with effects unknown and unknowable.

It is altogether probable that its effects will conflict with all currently established human conventions.

Maintaining the core values as established by the original author in the form of a reference implementation that is lightweight, coherent and cruft-free in face of this conflict requires deliberate effort involving multiple people, which in turn require management and guidance.

“THE BITCOIN FOUNDATION” will endeavour to provide these, while fostering community growth and development, under the general principle that if and when any other thing conflicts with Bitcoin, that other thing must either be discontinued or amended in such a way as to no longer conflict with Bitcoin.

Stan’s desire for a printed version of the reference Bitcoin implementationii provided the impetuus for the Bitcoin Foundation finally coallescing.

Since then work has been proceeding briskly in the salt mines of “peeling the layers upon layers of crap inserted by the Power Muppets since 2012ishiii”. Notwithstanding the appalingly poor quality of the original code drenched under all that ulterior cargo cultism and “lookma!Impatchsubmitting!”-ism, there is still plenty of hope that an actual Bitcoin reference implementation may eventually emerge from all these joined efforts. I, for one, am cautiously optimisitc...."
7  Bitcoin / Development & Technical Discussion / A summary of changes to Bitcoin since 0.3.21 on: October 21, 2014, 05:43:28 AM
The straight dope from Cascadian Hacker:

"Please enjoy this list of and commentary on a subset1 of changes to the Bitcoin protocol.

0.9.3
OpenSSL upgrade2
0.9.2.0 - 0.9.2.1
commands getwalletinfo, getblockchaininfo, getnetworkinfo added to support detangling of getinfo
oodles of GUI work
OpenSSL -> 1.0.1h
0.9.1
OpenSSL -> 1.0.1g
0.9.0
rebranded: Bitcoin -> Bitcoin Core (BIG STUFF, YO)
autotools build process (./autogen.sh; ./configure; make)
introduction of bitcoin-cli executeable ('cause don't make a correct thing, just keep derping at its edges, crufting layer after layer of duct tape on to the poor thing…)
"malleability"3-related fixes
"IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions"4
minimum fee required for nodes to consider relaying transaction fees dropped5
"Add getrawchangeaddress call for raw transaction change destinations"6
"Reject insanely high fees by default in sendrawtransaction"7
"New RPC ping command to request ping, new pingtime and pingwait fields in getpeerinfo output"8
0.8.6
"Default block size increase for miners."9
0.8.5
"Blocks containing transactions with version numbers larger than 0x7fffffff caused the code that checks for LevelDB database inconsistencies at startup to erroneously report database corruption and suggest that you reindex your database."
0.8.1 - 0.8.3
much UI
"MacOSX: * OSX support for click-to-pay (bitcoin:)"10
"The default fee for low-priority transactions is lowered from 0.0005 BTC (for each 1,000 bytes in the transaction; an average transaction is about 500 bytes) to 0.0001 BTC."11
0.8.0
"This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details)."12
"LevelDB, a fast, open-source, non-relational database from Google, is now used to store transaction and block indices."13
Introduction of Bloom Filters14
0.7.2
"Prevent RPC move from deadlocking. This was caused by trying to lock the database twice."15
0.7.1
"-salvagewallet command-line option, which moves any existing wallet.dat to wallet.{timestamp}.dat and then attempts to salvage public/private keys and master encryption keys (if the wallet is encrypted) into a new wallet.dat."16
0.7.0
"Transactions with zero-value outputs are considered non-standard"17
0.6.1 - 0.6.3
"added nonce value to ping"18
0.6.0
QR codes for sending and receiving19
new RPC call: importprivkey 20
irc peer scanning disabled
DOS protections21
multisig stuff
0.5.1 - 0.5.3.1
patch integrated that disallows new transactions with the same TXID as old transactions, unless all outputs from said have been spent22
"Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries)."23
0.5.0
"The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys."
new RPC commands signmessage and verifymessage 24
0.4.0
Wallet encryption25
multithreading deadlocks26
0.3.21 - 0.3.24
UPNP enabled by default for GUI client27
"Support for full-precision bitcoin amounts."
"New rpc command sendmany to send bitcoins to more than one address in a single transaction."
The takeaway: next to nothing has been done to bring the Bitcoin project forwards since 0.5.3 (the duplicate TXID rules). This (and the comments to code ratio) speaks as strongly to the failure of C++ as an expressive language that fosters the construction of (developer) performance-enhancing abstractions as it does to the failures of the group of humans who've sprung up around the thing seeking to make a buck; make a name for themselves as "Bitcoiners" or what have you; or even just a few miserable credits in the eyes of those who would print fiat currencies endlessly by derping relentlessly at its fringes.

Bitcoin Core is stalled out. It's gone precisely nowhere since 0.5.3 (unless you count the SSL patches that should never have been necessary in the first place).

Footnotes:

1
Subset criteria: things I found interesting.

2
Not necessary in any sense of the word, as you shouldn't be securing the connection to your remote bitcoin node via SSL.

3
Malleability is not and never was a thing. Referencing transactions by the hash you supplied at the time of submission to the memory pool and not the hash the miner who found the block in which they were so courteous as to embed your transaction blessed your transaction with demonstrates a poor understanding of transaction formation and block inclusion rules. Mt. Gox claims to have lost coins to this particular subtlety of the protocol, as they tracked transactions by the TXID they themselves generated, and not those the network blessed their transactions with. TXID's are changeable, as relaying peers maintaining the memory pool can change the scripts in a transaction without affecting signature validity.

4
So instead of accepting the protocol as it exists and as it works (just dandily, thank you for asking), the solution was to enforce more uniformity and homogeneity in what transactions are relayed through the memory pool. Mind you, this only affects the memory pool of upgraded nodes. Older nodes will continue to relay these transactions to miners very happily; those miners will happily accept transactions of adequate fee regardless of their IsStandard()-ness. Exercise for bitcoin pranksters: diddle as many transactions' scripts as possible in order to make 0.9 nodes hardfork. Much lulz will be had.

5
Another fairly smart change, if you're working for the USG and want to increase block sizes. Previously, you'd have not even bothered to send small-value transactions, as the fee required for the tx to propagate to the miners would make it uneconomical. If, however, you accept the mainstream derping about "banking the unbanked" (which itself is just a PR ruse of the USG's to get their fingers into the blockchain), you'll find yourself wanting to do something stupid about minimum transaction values in the bitcoin network. Once you reduce the minimum fee for broadcasting, a whole slew of smaller transactions will want into each block. That demand will put upward pressure on the price each transaction must pay for inclusion into each 1MB block, pressure that can only be alleviated by increasing the maximum block size. So there you have it: the USG is exploiting your kindhearted desire to make the world a better place for someone to whom you're entirely unrelated to fuck up the blockchain.

6
Doubling down on the "address reuse is evil and dangerous, bad for privacy and so on!" poor decisions. Sending your change to new addresses is, in the vast majority of scenarios, entirely pointless. The "hierarchical deterministic wallet" stuff is cool: being able to back up a single master key and have an arbitrary number of addresses keyed off it trumps the current behavior by miles.

The current behavior is for every transaction to spin up new addresses for change destination. This leads to wallet backups actually expiring - a phenomenally stupid thing that fell out of the poorly-thought-through "address reuse is evil, let's send change to arbitrary addresses" implementation shitshow. I look forward to finding when this actually happened at some point in my bitcoin archaeology. If, that is, I follow through in any detail.

7
More protecting idiot BTC holders from their own idiocy.

8
Prime example of the "feature development" that goes on instead of reimplementations. Derpy diddling at the fringes of things instead of actual contributions to ecosystem.

9
From Gavin's own notes: "…accomodate higher transaction volume, and to measure what percentage of hashing power simply goes along with defaults." Read as: "we're probing the network to estimate our ability to push stuff through, and if by chance we get people to run this code the blockchain will increase in size even faster lending credence to our other efforts to put strange into the reference client in a vain attempt to reduce blockchain size". Note the plausible deniability that comes from running one campaign to "keep the blockchain small" while all the while bloating it.

10
One of my least favorite integrations with host OS's and Bitcoin: "click this link to start your Bitcoin installation!".

11
Further efforts to increase demand for transaction inclusion in blocks, this time by reducing the default fee.

12
It's not a regression if you make it happen intentionally, guys!

13
Continues with "LevelDB works much better on machines…", which is pretty funny considering the LevelDB fixes required for very large version numbers.

14
An exercise I'd like to perform myself some day: estimate how many of the Bitcoin nodes out there support bloom filters. This would be a neat proxy for upgrade-rate.

15
The braindamaged "accounts" approach to BTC management lead to deadlocks. Well done, power rangers.

16
Bitcoin is written so well that it comes with its own utility to salvage wallet files (wallet files it probably fucked up in the first place)!

17
Attempting to ban zero-valued outs was no doubt a preliminary probing of the Bitcoin source control organization to see how well it handled stupid inputs. Clearly, it is a very forgiving machine, and gave the USG the notion it could start diddling with IsStandard() in hope of forking the blockchain in their favor.

18
I have always wondered why this was done. The official line is "to identify self connections" but…what?

19
Extremely! Very! Important!

20
This one's actually moderately useful. Note for future patchers of a stripped reference client: grab this one.

21
Denial of Service patches should also be brought into any future stripped-down reference client: doubtless the Empire's planning to hit any nodes that don't comply with their pending hardfork with DOS attacks.

22
The patch itself is an interesting read. Of code-culture note, there's ~2:1 code to comment ratio. A thing heard occasionally in my shop: "Whenever you feel compelled to write a comment, don't. Then, when you've refrained from crufting up the project with comments, write a test."

Of implementation note, I'm interested to know how this is acting now that nodes don't maintain a full index of TXID's. Future research project…

23
The lulz - they flow endlessly.

24
Part of the Imperial approach to crypto FUD. This introduced the notion of signing with one's bitcoin keys. While attractive to the nerdy, this is in no way a good idea as people are bound to get the wrong idea and associate Bitcoin addresses or keys with identity in some way. We've addressed this before but I'll summarize again: addresses are transient and should be treated as such. GPG keys are identity and should be protected as such.

Don't let anyone tell you that Bitcoin signatures are in any way a thing to use when you can use the full power of GPG instead.

25
Didn't work.

26
In c++? Surely not.

27
In the name of making things easy for the technically un-savvy to use Bitcoin, this is when it began advertising its presence to your home router."
8  Bitcoin / Project Development / Re: I created a simple BTC merchant processing solution on: October 19, 2014, 11:40:14 AM
Live demo: http://fullstack.ch/btcbox/

Feel free to drop some Satoshis in there to see the different images (all SFW), and contribute to the code on Github  Grin

Source: https://github.com/jswebdevel/btcbox

Background:

This is a stand alone system for accepting Bitcoin as a merchant. It requires a small amount of PHP/HTML/MySQL knowledge and a server. I built this in response to increasing demands for private information by third party processors, which creates barriers to entry for many merchants who may not even possess such information. It could also help merchants to rapid prototype business ideas at very low cost. Thanks to several members of this forum for code samples, one function I copied verbatim from here.

I plan to deploy this system in a more commercial environment in the near future. Hopefully some people find it useful/interesting for their own purposes - whether it is for education or commerce.

nicely done, forked it

LOL @ Thanks buddy, you're cool! img
9  Bitcoin / Bitcoin Discussion / A Decentralized Public Key Infrastructure with Identity Retention on: October 16, 2014, 10:20:34 AM
Somewhat amusing paper on decentralized[laff] PKI

From MIT/eprint (PDF):
"Public key infrastructures (PKIs) enable users to look up and verify one another’s public
keys based on identities. Current approaches to PKIs are vulnerable because they do not offer
sufficiently strong guarantees of identity retention; that is, they do not effectively prevent one
user from registering a public key under another’s already-registered identity. In this paper, we
leverage the consistency guarantees provided by cryptocurrencies such as Bitcoin and Namecoin
to build a PKI that ensures identity retention. Our system, called Certcoin, has no central
authority and thus requires the use of secure distributed dictionary data structures to provide
efficient support for key lookup."

..of course they had to give it a coin name - derps
10  Bitcoin / Bitcoin Discussion / BlueWallet: The Secure Bitcoin Wallet (bluetooth token auth) on: September 12, 2014, 08:45:38 AM
Interesting paper on bluetooth hardware token authentication for btc (not entirely novel, but nice approach).  Paid access article - lame.  Couldn't find it anywhere else.  You can read the first couple of pages for free.

From Springer:
"With the increasing popularity of Bitcoin, a digital decentralized currency and payment system, the number of malicious third parties attempting to steal bitcoins has grown substantially. Attackers have stolen bitcoins worth millions of dollars from victims by using malware to gain access to the private keys stored on the victims’ computers or smart phones. In order to protect the Bitcoin private keys, we propose the use of a hardware token for the authorization of transactions. We created a proof-of-concept Bitcoin hardware token: BlueWallet. The device communicates using Bluetooth Low Energy and is able to securely sign Bitcoin transactions. The device can also be used as an electronic wallet in combination with a point of sale and serves as an alternative to cash and credit cards."

related thing here used by a number of exchanges already.
11  Bitcoin / Bitcoin Discussion / VerSum: Verifiable Computations over Large Public Logs on: August 31, 2014, 08:34:37 AM
Amusing paper on blockchain-based data verification/authentication.

From MIT CSAIL (pdf)
VERSUM allows lightweight clients to outsource expensive compu- tations over large and frequently changing data structures, such as the Bitcoin or Namecoin blockchains, or a Certificate Transparency log. VERSUM clients ensure that the output is correct by comparing the outputs from multiple servers. VERSUM assumes that at least one server is honest, and crucially, when servers disagree, VERSUM uses an efficient conflict resolution protocol to determine which server(s) made a mistake and thus obtain the correct output.

VERSUM’s contribution lies in achieving low server-side over- head for both incremental re-computation and conflict resolution, using three key ideas: (1) representing the computation as a func- tional program, which allows memorization of previous results; (2) recording the evaluation trace of the functional program in a care- fully designed computation history to help clients determine which server made a mistake; and (3) introducing a new authenticated data structure for sequences, called SEQHASH, that makes it efficient for servers to construct summaries of computation histories in the presence of incremental re-computation. Experimental results with an implementation of VERSUM show that VERSUM can be used for a variety of computations, that it can support many clients, and that it can easily keep up with Bitcoin’s rate of new blocks with transactions.
12  Bitcoin / Development & Technical Discussion / Re: [PoC][Draft] The Bargaining Protocol (when BIP70 met the Bazaar) on: August 26, 2014, 08:33:57 AM
I like this very much. nice work
13  Bitcoin / Project Development / Re: New Bitcoin Business – Need assistance / advice on: August 26, 2014, 07:55:37 AM
This is a good place to start:
https://bitcointalk.org/index.php?topic=124441.0

http://blogs.bitcoin-assets.com/

Also, i encourage you to disregard "significant marketing..press-releases, articles, forum posts, videos, advertising and so on." 
Try to just focus on business fundamentals and spend all that time/energy instead learning/reading.

14  Bitcoin / Development & Technical Discussion / Re: Is there a good blockchain parser that is not Linux? on: August 24, 2014, 08:59:41 AM
here's another approach:
http://codesuppository.blogspot.com/2014/01/a-command-line-interface-for-blockchain.html
http://codesuppository.blogspot.com/2013/07/work-in-progress-on-bitcoin-blockchain.html
15  Bitcoin / Development & Technical Discussion / Re: Bitcoin-Postgres bridge on: August 24, 2014, 08:44:33 AM
this is cool. nice work; will use it
16  Bitcoin / Project Development / Re: Blockchain querying with mongodb on: August 13, 2014, 05:58:47 AM
do it.
17  Economy / Services / Bay Area Dev Positions: Android, iOS, Ruby, & Security on: August 08, 2014, 11:00:27 PM
I'm seeking to identify talent for a client.  Please contact me if you are in the bay area [or open to relocate] and meet the following requirements.  Reply with CV to admin@bitrecruiter.com

Compensation Ranges: $120-140k+ [possibly more for ideal candidate]

---

Senior Backend Ruby Engineer
Overview
Seeking to hire an experienced and motivated back-end ruby developer who wants to join a rapidly growing rockstar team to ensure mass Bitcoin adoption. You will be responsible for playing a leading role in our engineering team while building a Bitcoin wallet that millions of people will rely on for security, features, and performance. You will be tasked with full leadership responsibilities as they relate to strategic direction, engineering and technical operations.
Top Reasons to Work with Us Now
●   Tackling the biggest problem in the Bitcoin ecosystem: consumer adoption
●   Full leadership responsibilities with future growth and management opportunities
●   Ability to work with top talent from Stanford and industry
●   Get in early. We’re backed by Silicon Valley’s top VCs and investors with $2m in funding, and we still have a very small team
What You Will Be Doing
●   Lead the software development team to ensure consistent and timely delivery of our software products with a high-level of quality and architectural integrity while maximizing resources.
●   Champion of best practices for agile, design patterns and test-driven development
●   Monitor, report and execute the product roadmap, ensuring deadlines, budgets and milestones are met.
●   Establish and track clear, useful metrics which help us continually improve our processes.
●   Ensure easily maintainable code by creating and enforcing technical standards.
●   Ensure the product is efficient, stable and scalable.
What You Need for this Position
Technical:
●   4+ years of engineering experience building large-scale technical applications
●   Strong understanding of software development lifecycles
●   8+ years of software development
●   Experience with ruby on rails, javascript, linux, postgres/mysql, open source software, and AWS
Execution and Process:
●   Ability to operate in a startup environment and execute in the presence of ambiguity and change
●   Ability to handle a fast-paced environment and balance process with agility
●   Ability to fit in well within an informal environment and provide hands-on management.
●   Team-building skills to grow and hire future talent and foster growth and innovation
●   Talented leader who can become a key player in our organization
The ideal candidate:
●   Passionate about Bitcoin and cryptocurrencies with deep knowledge in the area
●   Located in the Bay Area
●   Experience in payments or financial services is a benefit
Benefits and Perks
●   Competitive salary and equity package commensurate on experience
●   Laid back work environment

●   Health benefits

●   Remote working options
●   Open vacation policy. We don't count days
●   Free transportation passes
●   Free gym membership
●   Flexible work hours
●   Relocation support

---

Senior Android Engineer
Overview
We’re is looking for an Android engineer to help us tackle the problem of creating the most consumer-friendly Bitcoin wallet for Android. We’re looking for a one-man team for Android as it will mainly be using our backend API.
Top Reasons to Work with Us
●   Tackling the biggest problem in the Bitcoin ecosystem: consumer adoption
●   Full leadership responsibilities with future growth and management opportunities
●   Ability to work with top talent from Stanford and industry
●   Backed by Silicon Valley’s top VCs and investors with $2m in funding, while still a very small team
What You Need for this Position
●   3+ years with deep understanding of Android UX and UI design paradigms, and ability to implement and design Android apps
●   5+ years of broad knowledge of Java, Eclipse and other IDE tools
●   Experience integrating with RESTful API backends
●   Experience with Unit Testing on the Android Platform
●   Ability and desire to thrive in a proactive, high-pressure, client-services, environment.
●   Experience with Android NDK (Native Development Kit)
●   Experience with Android PDK (Platform Development Kit)
●   Experience with AOSP (Android Open Source Project)
Details
●   Location: San Francisco
●   Full-Time (also accepting interns)
●   Starting immediately
Benefits and Perks
●   Competitive salary and equity package commensurate on experience
●   Laid back work environment

●   Health benefits

●   Remote working options
●   Open vacation policy. We don't count days
●   Free transportation passes
●   Free gym membership
●   Flexible work hours
●   Relocation support

---

Senior iOS Engineer
Overview
We’re is looking for an iOS engineer to help us tackle the problem of creating the most consumer-friendly Bitcoin wallet for Android. We’re looking for a one-man team for iOS as it will mainly be using our backend API.
What You Need for this Position
●   3 - 5 years software development experience building client applications on mobile platforms.
●   Proven track record of developing complex and intuitive interfaces for mobile applications and successfully launching apps in Apple App Store.
●   Strong knowledge of Object Oriented design and programming skills in Objective-C.
●   Comprehensive experience utilizing iOS frameworks to help create user interfaces that are fast and user-friendly.
●   Highly motivated individual, proactive in defining and solving difficult and innovative problems.
●   Expert knowledge of iOS Core Data framework a plus.
●   Bachelors Degree in Computer Science or equivalent.
Details
●   Location: San Francisco
●   Full-Time (also accepting interns)
●   Starting immediately
●   Benefits and Perks
●   Competitive salary and equity package commensurate on experience
●   Laid back work environment

●   Health benefits

●   Remote working options
●   Open vacation policy. We don't count days
●   Free transportation passes
●   Free gym membership
●   Flexible work hours
●   Relocation support

---

Senior Security Engineer
Overview
Seeking to hire an experienced and motivated security engineer who wants to join a rapidly growing all-star team to ensure mass Bitcoin adoption. You will be responsible for designing and building secure software from the ground up, as well as breaking and refining our current architecture. You will play a leading role in our engineering team while building a Bitcoin application that millions of people will rely on for security, features, and performance. You will be tasked with full leadership responsibilities as they relate to strategic direction, engineering and technical operations.
Top Reasons to Work with Us Now
•   Tackling the biggest problem in the Bitcoin ecosystem: consumer adoption
•   Full leadership responsibilities with future growth and management opportunities
•   Ability to work with top talent from Stanford and industry
•   Get in early. We just closed funding with Silicon Valley’s top VCs and investors, and we still have a very small team
What You Will Be Doing
•   Champion best practices in building secure software
•   Build new features to make users and data more secure
•   Own projects from inception to completion
•   Proactively identify and fix security vulnerabilities in the platform
•   Provide expertise to other engineers in the designing and building of secure software
•   Ensure easily maintainable code by creating and enforcing technical standards.
•   Ensure the product is efficient, stable and scalable.
What You Need for this Position
Technical:
•   Strong foundation and in-depth technical knowledge
•   4+ years of engineering experience building large-scale technical applications
•   Strong understanding of software development lifecycles
•   8+ years of software development
•   Experience with ruby on rails, javascript, linux, postgres/mysql, open source software, and AWS
Execution and Process:
•   Ability to operate in a startup environment and execute in the presence of ambiguity and change
•   Ability to handle a fast-paced environment and balance process with agility
The ideal candidate:
•   Passionate about Bitcoin and cryptocurrencies with deep knowledge in the area
•   Located in the Bay Area
•   Experience in payments or financial services is a benefit
Benefits and Perks
•   Competitive salary and equity package commensurate on experience
•   Laid back work environment

•   Health benefits

•   Remote working options
•   Open vacation policy. We don't count days
•   Free transportation passes
•   Free gym membership
•   Flexible work hours
•   Relocation support
18  Bitcoin / Development & Technical Discussion / Re: A protocol for easy p2p message broadcasting - FastCast on: August 01, 2014, 11:01:38 PM
Very cool. Nice work
19  Economy / Securities / Re: MPEx securities discussion thread on: July 27, 2014, 05:45:29 AM

AM has been failing spectacularly since its listing on Havelock.  Like so:


Those charts are listed in btc -which has obviously endured a meteoric rise over the last few years..so ANY btc priced asset will display downward trend as its valuation adjusts to fiat market prices...unless the security were to have some impossible trajectory exceeding bitcoin's surge in value..which is quite unlikely.

If you wish to understand actual valuations  for stocks listed in btc, you need to do a bit of calculus.
20  Economy / Securities / Re: MPEx securities discussion thread on: July 27, 2014, 05:31:31 AM
...
It doesn't seem worth debating further as your argument is clearly emotional, irrational heresay.  

I asked if you could demonstrate a shred of evidence to support your claims of mpex impropriety.

Pages: [1] 2 3 4 5 6 7 8 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!