this is a serious question
would you sell very small amounts of this land? like a few square yards
No, sorry. |
|
|
|
|
It is difficult to take this complaint seriously, lacking similar protests for people to stop using SSL + existing CAs when visiting bitcoin websites.
A certain user class is already using certificates and digital signatures.
|
|
|
|
Frankly I think that's awful advice in the case of Mastercoin and similar systems, precisely because they can get away with using standard transaction to achieve their goals.
Why risk having the reference client maintainers reject your transaction standard if you don't have to?
That presumes additional checks on pubkeys are not coming down the pipe, which is also awful presumption / advice. |
|
|
|
Note that http://eligius.st/~wizkid057/newstats/pushtxn.php will push a non-standard, fee-bearing transaction into Eligius-mined blocks. Thus there is no requirement to fit the mold of a "standard" transaction that is relayed by most. Typically the development process looks like - Design the best transaction format
- Write software, prove it works on testnet
- Test on mainnet through manual miner submission, like the Eligius URL above
- Now you have a proven use case, and time has passed proving that your concept remains interesting to some user base somewhere
- Submit a patch to bitcoin/bitcoin.git, adding that transaction as a standard transaction
Some of these steps may be done in parallel, of course. |
|
|
|
Enough with the whitepapers. We don't need another freakin' whitepaper. Ideas for decentralized exchanges have existed for years. We need code. |
|
|
|
I don't think we should use invalid ECDSA points if at all possible though as we'd be making it blindingly easy to censor mastercoin; the bitcoin devs could simply enforce ECDSA point validity checking on multisig pubkeys and we'd be in trouble.
This is already being implemented, in fact. Nothing to do with mastercoin. |
|
|
|
|
Yes, the genesis block is hardcoded into the client.
|
|
|
|
|
Related:
Similar to each bitcoin P2P peer's nonce value, which serves as a node's unique id, I've occasionally desired for each side of the P2P protocol to offer a random seed in "version" and "verack."
(a DH exchange is probably too much to wish for, in the context of bitcoin P2P, heh heh)
|
|
|
|
The only reliable solution is to source your coins in small values, so you don't need to split value. Yet this is not possible if the payer is splitting and paying you numerous times, e.g. an employer.
This is actually an interesting problem, that is difficult to solve with current bitcoin. Entities that issue regular payouts -- in my case, ASICMINER, Eligius and my employer BitPay -- inevitably set up a single payout address, and then send multiple payments to that address. This is certainly sub-optimal, and reduces privacy. No amount of CoinJoin'ing by itself will fix this multiple-payout/single-address problem. We'll call it "recurring incoming payments." Recurring incoming payments -- and recurring outgoing payments (subscriptions) -- are problems that bitcoin is quite unsuited to address right now. To increase privacy, those who pay out need some standardized way to request multiple addresses from their payees. |
|
|
|
… and get your money stolen or get LE easy access? Come on, the bitcoin idea is be your own bank. No third party risk should be acceptable for the more security aware people.
Indeed. Bitcoin is decentralized... the antithesis of bitcoin is really centralized websites and authorities. |
|
|
|
|
Any possibility of getting recent IPs from the server log -- last 7 or 30 days -- and produce an anonymized, by-country summary?
It would be nice to see which countries are most interested in JD. I bet there is some interest in China, even.
(and a Chinese translation might bring more players)
|
|
|
|
|
Hopefully the cold storage is protected by multisig, so that dooglus alone cannot unlock it.
|
|
|
|
|
Is this meetup held on a regular basis? Same day of the month and location?
|
|
|
|
|
getblocktemplate provides a set of candidate transactions. You are able to supplement or cull that set, before passing a block header template to miners.
|
|
|
|
I think this is going to hurt CampBX much more than it will Dwolla, and it for Bitcoin it is only a matter of wounded pride. Now the only way to get money to them is by using postal mail via money orders or personal checks. No wire transfers, no ACH.
This is false. CampBX works fine with ACH. CampBX recently restated this on Facebook, following the Dwolla shutdown: https://www.facebook.com/CampBX/posts/665137400165381 |
|
|
|
|
Field experience -- the kind an engineer like myself most respects -- indicates that any centralized securities platform might get shut down, hacked, or simply disappear without warning. These events have all happened in the past. This is not idle speculation about vague threats.
|
|
|
|
Please, instead of these endless discussions, write some code. Even it doesn't work very well. At least you'll see what are the issues.
I posted links to code, even... Additionally, this code submission for upstream bitcoin is intended to help enable a standard way of encoding metadata -- such as stocks/bonds, rather than current ad hoc methods such as the one employed by mastercoin. Relay OP_RETURN data TxOut as standard transaction type. https://github.com/bitcoin/bitcoin/pull/2738 |
|
|
|
All a shareholder registry needs is a robot/service that receives and verifies digitally-signed messages, updating a ledger of share accounts. This can be automated today using GPG tools, if PGP is used, or bitcoind, if ECDSA is used.
Other parties -- as shown in the past -- will create pass-through entities for the various exchanges that exist.
Frankly, I would not trust a third party to 100% manage my company's shareholder list. But that's a business decision. Plenty of Fortune 500 companies hire a 3rd party platform to manage their shareholder registry.
That is not decentralization, it is breaking out a piece of the puzzle to attempt to remove trust from one part the equation. It would not prove flawless, nor exempt from trust requirements anyway. Nowhere was it claimed to be anything more than one piece of the puzzle. Given all current field experience with unregulated securities, Any company would be unwise to place their shareholder roster 100% in the hands of an unregulated third party. Take a cue from ASICMINER, that developed a working method after GLBSE's collapse. |
|
|
|
|
Show Posts
