Very nice write up. There are some libraries like bitcoin-js that do accomplish that task, but they aren't very well documented, so your work is definitely welcome here. One note - The version byte can have up to four valid values for Bitcoin network: - 0x00 - main network pubkey hash address - 0x05 - main network script hash address (e.g. multisig address) - 0x6F - test network pubkey hash address - 0xC4 - test network script hash address More information: https://en.bitcoin.it/wiki/List_of_address_prefixesObligatory, related plugs: https://github.com/gasteve/node-libcoin (bitcoin JS library, for node.js -- an update of bitcoinjs-server) https://en.bitcoin.it/wiki/Identity_protocol_v1 (also uses base58-encode-check and a well known prefix) Thanks, I wasn't aware of node-libcoin despite being so heavily invested in the Node.js community: https://npmjs.org/~jp. Jeff, it looks like you're one of the authors of the Node.js libcoin. I'm curious, why did you choose to do the ECC code in C++? Using OpenSSL is important for bug-for-bug compatibility, even ignoring the performance improvements. |
|
|
|
|
Updated block chain torrent to height 250,000, coinciding with a recently commited checkpoint in the bitcoind source code.
Existing seeders, please update by simply swapping out the old torrent file for the new torrent file. After restarting your torrent client, you should already have ~85% of the new bootstrap.dat.
New seeders: We always need more seeders, in every country of the world, to help spread the block chain and speed downloads. Ideally, we have a large swarm of seeders, that burst to downloads at maximum download speed, and then remain idle the rest of the time.
Read the OP for magnet link and torrent details. Ask questions.
|
|
|
|
Very nice write up. There are some libraries like bitcoin-js that do accomplish that task, but they aren't very well documented, so your work is definitely welcome here. One note - The version byte can have up to four valid values for Bitcoin network: - 0x00 - main network pubkey hash address - 0x05 - main network script hash address (e.g. multisig address) - 0x6F - test network pubkey hash address - 0xC4 - test network script hash address More information: https://en.bitcoin.it/wiki/List_of_address_prefixesObligatory, related plugs: https://github.com/gasteve/node-libcoin (bitcoin JS library, for node.js -- an update of bitcoinjs-server) https://en.bitcoin.it/wiki/Identity_protocol_v1 (also uses base58-encode-check and a well known prefix) |
|
|
|
Yeah. But then you need to assume that they are stupid and so when you say them "buy 1264 shares of ABC and 1734 of DEF" (where ABC and DEF are a rarely traded assets), they are actually buying the exact amount of both of them... which they should not, if they are smart and don't want to get busted.
It is tough to do real-time trading and avoid that problem. |
|
|
|
I'm sure it would be trivial to discover the owner by making signature investments on certain scales and identifying the pattern on an exchange.
+1 I was also curious about dividends. That would be ideal: a [non-anonymous, sorry TorBroker] service that allowed me to - deposit bitcoins
- trade US securities
- receive dividend payments, instantly converted to bitcoins, and credited to a bitcoin balance
- withdraw bitcoins
|
|
|
|
|
Definitely an ambitious and exciting service. Glad to see it. This sort of investing is key to growing bitcoin, and creating "100,000 little links" with the legacy financial world.
Problem #1: impossible to prove this is not a scam, besides actual service testing and observing the results.
Problem #2: US capital gains tax liability, which the operators presumably must pay
Problem #3: Bitcoin income/exchange tax liability, and other regulatory risk. Move any significant amount of money into TorBroker, and it is noticable that you are suddenly appearing at your brokerage's doorstep with USD cash from already-watched bitcoin exchange sources.
Even assuming 100% honest site operators, a more realistic fee seems like it would be closer to 33% to cover all taxes, since operators seem unlikely to be able to prove to the IRS that receiving thousands/millions of dollars in bitcoins is not income.
Disclaimer: Of course, for legal and risk related reasons, I do not plan to actually connect to the website.
|
|
|
|
|
How about this... encourage automatic decentralization.
1. Update mining software to automatically rebalance between pools, based on a variety of factors. Some miners and proxies already do a bit of this.
2. Measure the size of pools, and select pools to help avoid one or two pools having large shares of the network power.
|
|
|
|
|
BTC Guild's switching seems to have worked out just fine.
They assign shares to rounds, and changed the "N" value between rounds, when they needed to change.
|
|
|
|
|
This received several bug fixes, by way of its use of python-bitcoinlib.
|
|
|
|
|
Updated with several bug fixes, and some new modules (bloom filter).
|
|
|
|
Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/GetworkOn mainnet, almost everybody uses a pool (and therefore, not "getwork" directly to bitcoind). Those few who solo mine use a pool server to talk to bitcoind via "getblocktemplate" or other means. Tests show that attempts to solo mine on mainnet via "getwork" lead to delays and problems. On testnet, getwork has a better chance of continuing to work. Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork. However, at one time, getwork to bitcoind was widely used. I wanted to poke the audience, to gauge response to removing "getwork." If a driving use case remains of which we're unaware, speak up, please. We don't want to break anybody needlessly. |
|
|
|
Using the term "miner" to refer to both those creating the coinbase tx (and rest of block structure) and those who merely attempt to find a solution to that problem is vague at best. This may have implications beyond just network security. FinCEN's guidance on miners (as illogical as it may be) puts a distinction on the entity "creating" currency units. A legal argument could be made that Satoshi created all the currency units and miners (true miners, pools, solominers, p2pool members) are merely being rewarded them for block completion. However even if that argument fails it would seem that pool workers wouldn't be creating currency units regardless.
+1 this will become relevant in the future. Two years ago, I speculated on the legal ramificiations of running a mining pool -- that is, being the one who selects the coinbase payouts, and in turn, transmits a bunch of bitcoins to a bunch of others. Solo miners have one level of risk (coinbase payouts), and mining pools have an additional level of risk (coinbase payouts + miner payouts). I wouldn't be surprised if mining pools in the US required KYC/AML verification. The best argument can be made for the end-of-line miners. They do not control the coinbase nor payouts, and the best case may be made for them as providing a computing service, in exchange for bitcoins. |
|
|
|
|
+1 everything transferred as expected
|
|
|
|
Hopefully ASICMINER mines their own payouts!
From experience, they don't. Usually it's delayed because of unconfirmed inputs though... using a low fee is just stupid. Well, One standard miner practice is to behave economically rational: make the transaction zero-fee, and include it for free in a block that you mine. Including mining-pool-specific transactions in blocks you mine has been common for years, and I encourage ASICMINER to do the same. |
|
|
|
|
0.9 will largely be feature driven, not schedule driven.
Payment protocol is one goal, and that is close to merge.
|
|
|
|
So a friend of mine looked at one of these subpoenas last night. They are very detailed documents, lot's of requirements but nothing seems to be out of MSB scope. I hope I am still right about this.
Dying to read actual subpoena text... Does the subpoena include confidentiality clause, preventing the sharing of its contents? |
|
|
|
|
Still awaiting share transfer confirmation.
|
|
|
|
|
Show Posts
