|
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.
|
|
|
|
Have any of these critics contacted bitcoin websites, asking them to stop using SSL w/ public CA? No? I thought not. For, the payment protocol will be used where there is already a digitally secure relationship between customer and merchant. So much for section 10 of the white paper. privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.
Nothing about that section changes. Bitcoin-QT still tries to use a new key for each transaction, just like that section describes. The payment recipient (merchant) still knows just that public key hash, but not about your other transactions. Methinks there is some basic reading comprehension fail going on. |
|
|
|
A branch would increase work required, rather than decrease. Here is the current rough plan: The first step is basically complete: a runtime no-wallet mode: https://github.com/bitcoin/bitcoin/pull/2901 Later on, this may be extended to #ifdef'ing out wallet code, once the "no wallet" runtime code has been proven to work. Next, headers-first sync, which fixes many issues with the bitcoin block download process in general: https://github.com/sipa/bitcoin/tree/headersfirstOnce these features in place, it becomes feasible to have the wallet client operate in a separate process from the public blockchain engine. At that point you have a stripped down "blockchain engine" (border router) that focuses on mesh networking and accurately maintaining the chain. |
|
|
|
Absolutely. It would be quite nice if wallets support Trezor, including Bitcoin-QT. Well Trezor is cool, I don't argue that but it's conceptually wrong to add excess features to a bitcoin wallet program that should be the most trivial and standard one. You can always make a new program that would act as a proxy between bitcoin QT and Trezor. Thus, I still don't support the idea of bloating the standard wallet with anything other than what the bitcoin protocol needs. Bitcoin QT should be commercially neutral. This means that it should not feature any entity that gets direct monetary profit from such features. Introducing features that glorify CAs is on the same level of wrongness as adding the following text to the Bitcoin-QT's GUI: " Click here to buy bitcoins from Mt. Gox!" Making the user experience more resistant to MITM attacks is not bloat. |
|
|
|
Absolutely. It would be quite nice if wallets support Trezor, including Bitcoin-QT. |
|
|
|
May I humbly request some help from the Chinese bitcoin community? I am trying to discover my Chinese name, hopefully something short. There is a small discussion on G+ https://plus.google.com/u/0/105424721218711536033/posts/Nk3DzpcoChD but the forums seem like a logical place to ask. Apologies if this is not the right forum. Hope to travel to mainland and HK next year. (hint: ping me, if there is a good bitcoin meetup or conference in China...) |
|
|
|
Believe in whatever wild conspiracy theories you like. There's no way I can give a good rebuttal to things that aren't happening. The rationale for these changes has been laid out in detail. If you think you found a government-proof way to achieve the same goals without the CA infrastructure, please do go ahead and implement it.
In all fairness, it has become a FAQ. Given NSA/PRISM fun, it seems likely to remain so, no matter the hard evidence. I got several variants of this question/complaint at the Atlanta crypto-currency conference, and reddit mirrored more of the same. Given there are quite some voices of doubt in the community (see Hyena above) the question is does this have to go into the standard client right from the beginning? Maybe this topic should be:
"VOTE on the payment protocol and the CA system to be included in standard client"By virtue of existing https use, the voting is active and ongoing. The only robust, deployed systems in active use are SSL and PGP. |
|
|
|
Believe in whatever wild conspiracy theories you like. There's no way I can give a good rebuttal to things that aren't happening. The rationale for these changes has been laid out in detail. If you think you found a government-proof way to achieve the same goals without the CA infrastructure, please do go ahead and implement it.
In all fairness, it has become a FAQ. Given NSA/PRISM fun, it seems likely to remain so, no matter the hard evidence. I got several variants of this question/complaint at the Atlanta crypto-currency conference, and reddit mirrored more of the same. The core points I like to mention are - There is a high likelihood that SSL & standard CAs are being used anyway. It is probably a browser launching a payment from an https:// supplied page
- The payment protocol does not mandate SSL + standard CAs. Other methods, including decentralized methods, are possible.
Perhaps it would be a good idea to specify a decentralized example. PGP comes to mind, or a self-signed ECDSA scenario of bitcoin address or SIN. |
|
|
|
The identity problem can be solved with Namecoin. Trust is the hard part but I'm sure it is possible and will come.
Not namecoin alone. Namecoin is just a storage method. |
|
|
|
I think the site needs improvement. Investors might help with that. But instead of doing it the way we do it now, whoever shouts loudest on the forum or in the chat, why not let them actually vote on an issue. Weighted by their investement (and time), like I said.
dooglus what do you think about this idea? Easily gamed: nakowa shows up, deposits 11,000 BTC, obtains > 25% of the vote, votes, and then withdraws. |
|
|
|
In general, though, I believe I will be doing a variant of your list option #2. Up to X BTC in fees to miners, remainder held by the pool. This will let Eligius keep with its informal policy of returning accidental transaction fees to their owner (with signmessage proof for all inputs), minus X BTC. After a certain amount of time has passed with no claim then the balance could be released to miners. It is very obvious that any transaction with a large transaction fee is likely a mistake at this point.
I do believe that long term Eligius will need a % of the transaction fees (NOT BLOCK REWARD) for expenses to survive.
Yes. Set this up initially, when transaction fees are small, e.g. - Eligius claims 10% of transaction fees, for pool expenses -- maybe even higher initially, like 50%, but plan to decrease percentage over time
- Plus a safety valve, if fees exceed 25 BTC in a single block (or pick your number)
1. Add transaction fees to the 25 BTC rewarded to miners at the top of the share log when a block is found, thus paying more shelved shares using transaction fees.
Yes, this is a nice option. |
|
|
|
i am thinking of let my both jupiter mine here. if i understand the CPPSRB system right it seems to be a nice payout method. the only thing i am afraid of is if i will earn the same amount of btc if i use elligius instead of btcguild (pplns) or 50btc (pps).  Actually, long term you should earn more with Eligius than most other pools, regardless of their reward system, since Eligius has no fee. Respectfully, that is not true as long as some pools give their users network transaction fees, and Eligius does not. Transaction fees can add 1% or more to a miner's income. It is important to pay some percentage of transaction fees to miners. This provides virtuous economic signalling to miners and users alike. I would propose moving Eligius to a rule like - Takes X percentage of all transaction fees (10%? 50%?) Right now it is 100%.
- Take no more than Y BTC in a single block, paying 100% of fees above Y BTC to miners.
|
|
|
|
Tor relays is any interesting concept, there is already a demand for anonymizing internet usage. Using Bitcoin to monetize an agent to do so would only expand and strengthen that network. Now the real question is how could you deal with microtransations on that scale?
Micropayment channels can scale to multiple agents and such. I do not think it is really a big deal, though. For a Tor relay, I would just want to pay a $entity, and have that payment support "the network." Also, even harder, how do you protect anonymity if you also have to pay the nodes?
It would be a poor user interface, if the user must manually select node 123 and pay node 123. |
|
|
|
Can anybody verify that in the code example above; nValue is the (Bitcoin) amount and (int)GetSerializeSize(SER_DISK,0) the bytesize of the output script.
nValue is the bitcoin amount, in satoshis. GetSerializeSize() is the serialization of the transaction output, not the script. |
|
|
|
His description of the WoT as being a "quasi-religious hacker ritual" made me laugh. That pretty much sums it up.
It is. That is why I am so unenthusiastic about key signing. Beyond a single, direct connection, it's just geek wanking. That is also why I do not think cjdns, with its WoT-like model of "only connect to your friends" will ever scale to any useful size. cjdns is otherwise quite nice. |
|
|
|
My transactions were being flagged as non-valid whenever I used 0.00006 for the multisig output, changing this to 0.00006 * 2 fixed this for some reason.
Do you happen to recall/have notes on what error was returned? I think I got a very non-informative tx-reject (error 22). I think the debug log mentioned something about it being a non-standard transaction. I will check it out tonight if I can find some time  That's because the amount is below the dust threshold (0.000534 or thereabouts). |
|
|
|
I mean you could essentially just write a wrapper for it. Let the user decide if they want a spot instance, reserved, etc
Certainly. My message about spot instances was mainly about a possible business opportunity. * jgarzik wrenches self back on-topic... Fair enough. Are there any other Autonomous Agents concepts floating around? I've only really seen StorJ held up as the shining example. Just really want more to read on the topic. In the fiction world, I highly recommend Daemon by Daniel Suarez, and its sequel. All other fiction seems to present an unrealistic, Hollywood, human-level AI, if it is a robot spending money. I've only ever seen the links referenced in the OP, referring specifically to narrow-AI agents that can spend money. Now, there is plenty of research outside of the economic realm, on autonomous vehicles and swarms. Just about any vehicle imagined -- submarine, boat, airplane, helicopter, car, tank, ... -- can be autonomous, and communicate with other non-human objects in its environment. It seems like our community is the only one actively researching this area, robots + money + markets. (Correct me if I'm wrong, please!) |
|
|
|
I mean you could essentially just write a wrapper for it. Let the user decide if they want a spot instance, reserved, etc
Certainly. My message about spot instances was mainly about a possible business opportunity. * jgarzik wrenches self back on-topic... |
|
|
|
|
Amazon spot instances can be pretty cheap, and they are on-demand too.
If an automated system is being constructed, it could query spot instance prices and take these things into account. Example: AWS normal price is X, spot instance price is X*0.75. You can bid X*0.9 for a spot instance, be likely (but not guaranteed) to have the instance keep running, and probably come out with a cost below the normal AWS price pretty consistently.
Anyway, don't get too distracted by that, just wanted to point out that Amazon already has a nifty, dynamic pricing system in there.
ETA:
Another anti-fraud trick is a deposit (or, getting more complicated, a fidelity bond). Require a 0.5 BTC deposit, or a certain amount of pre-paid service, if you do not have a SIN with a good reputation.
|
|
|
|
|
Show Posts
