|
It is an engineering statement. Information is, in general, easy to copy and leak, and difficult to keep secret.
|
|
|
|
|
For Phase 1, dealing with investors/shareholders would just be far too annoying. It would get in the way of getting things done.
|
|
|
|
One of the key tenets is that bitcoin block data is easy to distribute widely. Information wants to be free. One of the ways we may keep bitcoin healthy and free is finding alternative ways to distribute block chain data. This provides resilience in case the P2P mesh network is attacked. My personal favorite is satellite distribution, something I have been working on quietly in the background. Satellites means one of two things: - 1. Buy some bandwidth on an existing satellite.
- 2. Launch your own satellite.
Buying bandwidth is the most cost-effective, and readily attainable method today. However, not just any satellite channel will do. Bitcoin requires a dedicated, one-to-many broadcast mechanism. This is like renting a TV channel -- although at much lower bandwidth requirements (1MB every minute or two). Nanosatellites have recently cut satellite costs down from the absurd, traditional $20m+ build, $50m+ launch. There is now a standardized cubesat size. Two innovations reduced launch costs down into the $100k's range: (1) Many organizations collaborate together (rideshare), paying a portion of the launch cost. Sometimes 27 or more cubesats are launched at once. (2) These clusters of cubesats are launched as a secondary payload. A primary payload has priority, which means secondary payloads are sometimes not launched into a proper orbit. With these two factors, cubesat construction and launch is lowered to a reachable price: $2m or so. Several people, including some investors, in the bitcoin community have privately expressed interest. It seemed like a good time to move forward with Phase 1 of the project. Phase 1 is: flesh out cubesat specifications, research leased bandwidth pricing, and specific data needs (xmit tech, frequencies). The initial goal is broadcasting worldwide (or at least major continents) the latest bitcoin block, over and over again. Stretch goals include broadcasting recent chains, recent TX's, and other data. A word about government involvement: Set expectations properly. There are three points at which government is inevitably involved, at some level: (a) getting launch approval, (b) ground station(s) inevitably must be located in some useful geolocation, and (c) frequency selection. Fundamentally, these satellites will be broadcasting public, not-encrypted blockchain data, so the content should not be an issue. Donations accepted at 1M9MyyPsAak7zRjW4D96pTxDaAEpDDZLR7Feb 05 update:Project update #1: PermalinkBitSat architecture, v0.1: PermalinkFiles posted on http://bitsat.org/#/docsSponsors (1 BTC or more): - Mohit Kalra (2 BTC, May 2014)
- Unknown (1 BTC, Apr 2014)
- http://www.redstarmining.com/ (1 BTC, Jan 2014)
- Roger Ver (5 BTC, Dec 2013)
- Erik Voorhees (5 BTC, Dec 2013)
- Rusty Russell (1 BTC, Dec 2013)
- BitcoinGrant.org (25 BTC, Nov 2013)
- Jeff Garzik (1 BTC, Nov 2013)
Standard disclaimer: This is a personal project. Nothing to do with my employer. |
|
|
|
|
The software ecosystem is missing a useful piece:
When you are receiving regular payouts, from a job salary or mining pool for example, there needs to be address rotation.
Right now, the only way to do that is manually logging into the payer's website, and replacing the current payout address with a new one.
Software should communicate with the payer, or give the payer a list of addresses, or an HD seed that may generate additional public keys, etc.
Address reuse in these circumstances is annoying, hurting privacy, but inevitable until software improves.
|
|
|
|
I have long been a proponent of a merge-mined "data chain" which is specifically designed for smart property, colored coins, and mastercoin metadata. Even did a tiny bit of work creating an (unseen to the public) "DataNet" codebase, whose work is both obvious and long since outdated. The keys are - Emphasize tech neutrality, and engage other projects outside MasterCoin to use the data chain. Even up to and including patch contributions to third party projects.
- Approach pool operators, request merged mining of this chain. Point out how it's a community chain.
- Do not premine, or other scamcoin traits.
- Be very explicit about intended chain uses, and aggressively work with pool ops to de-spam.
|
|
|
|
|
Just visit any block explorer, to see the balance at a particular address.
|
|
|
|
This is huge, because it means you can give out multi-sig addresses to your users and actually be able to credit them when the coins arrive!
That's standard fare, with pay-to-script-hash (P2SH). Multisig P2SH addresses are easy. "addmultisig" RPC call handles this, for bitcoind / Bitcoin-QT. |
|
|
|
Artificial mining fees give an advantage to very large miners and could foster centralization. E.g. BTC guild with 28% hash power can easily give you a 10% discount on sacrifices and still make 18% profit. Even more so if the first sacrifice tx is not released other than as part of an (orphaned) block.
A bit, but this is addressed somewhat: Read the SIN spec, and how announce/commit sacrifices work. The protocol is specified such that you are required to have made the transaction available to all for mining and spending, for a period of time, before committing the sacrifice. Of course as Greg noted, fixing the problem of pool-centralization is sadly outside the scope of this work, and more fundamental to bitcoin itself. (encourage p2pool use...) |
|
|
|
I dare to state (and I am dying to be proven wrong) that making a wallet-less reference node, with minimal external dependencies will never happen - at least not made by this team. It just isn't on their employers' agenda, despite of all the rumors and gossips that you might have heard.  no-wallet mode will be in version 0.9. |
|
|
|
One thing that immediately springs to mind in terms of the more positive consequences: could this form the basis of the decentralisation of the various centralised technology services that are subject to abuse now
That's the general idea. Your markets can be decentralized, as long as the identity protocol is agreed upon. You control your own level of privacy. You choose to whom your identity is revealed, and beneath that, the meaning of the hashes attached to your SIN record. |
|
|
|
Does it need to be able to include additional data such as name, ssn, etc? That sounds like a bloat bomb as there's no upper limit to what information folks will want included plus it adds to the risk, wouldn't it be better as a simple unique identification and let 3rd parties and/or a namcoin like chain handle the data associated with it?
None of the SIN data is in-chain except for the sacrifice transactions. The main bitcoin blockchain is only used for timestamping a hash of the public key (SIN type 1). SIN type 2 is completely off-chain, because it is not associated with any sacrifice. |
|
|
|
SIN uses OP_RETURN: https://en.bitcoin.it/wiki/Identity_protocol_v1Though as Peter has noted elsewhere, the current OP_RETURN standard (max 80 bytes) is smaller than the needs found in the SIN specification, which must include a full transaction. |
|
|
|
This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?
bitcoin: URI hander. |
|
|
|
|
The bitcoin client does not connect to the CA.
Stop repeating clueless people.
|
|
|
|
|
As Luke indicated, "nobody to longpoll" is normal for pools without getwork/getblocktemplate (GBT) users.
|
|
|
|
|
The OP_RETURN patch for transaction metadata was just merged into bitcoin/bitcoin.git.
|
|
|
|
|
Show Posts
