|
Updated first post to reference NEW articles thread.
|
|
|
|
The following domains are expiring soon, and are available for sale if anyone wants to grab them before they go on the market: bcfx.co bcfx.us bcfx.org bcfx.biz bcfx.info bcfx.eu bcfx.cc bitbanc.com bitforex.co coinfx.co emultipay.com fxbit.co fxbit.com Any offer is acceptable. Email jgarzik@exmulti.com to make an offer. |
|
|
|
edited
Appreciated... but note the format is YYYY for a four digit year. For some examples, look at the rest of the Press board. |
|
|
|
|
Please update subject to use standard YYYY-MM-DD format at beginning, as noted in Guidelines for this board.
|
|
|
|
|
Not sure this qualifies as "press" but I'll leave it alone. The purpose of the board is not to list promotions by bitcoin fans, but more when the outside world notices bitcoin, i.e. journalist articles, TV shows, scholarly articles in scientific research publications, etc.
If we get too many of these, moderation might have to tighten a bit (but as I said, I'm leaving this one untouched, preferring to err on the side of caution)
|
|
|
|
Probably because theymos got around to creating the "press" sub-board just today.
I noticed theymos moved the 'Bitcoin hits' thread to the new Press board, and jumped on that. |
|
|
|
The Press board replaces the Bitcoin press hits, notable sources thread. The original motivation of the thread was to collect links that fit Wikipedia's definition of Notability. Once bitcoin was deemed sufficiently notable (a milestone!), the thread became an ongoing log of links. Discussion was discouraged. The Press board is a great improvement. These general guidelines should help keep the board usable: - Create a new thread for each new link
- Begin each thread with article date, YYYY-MM-DD format.
- Thread title should usefully summarize the link. julz has suggested DATE-SITE-HEADLINE format, but use your best judgement.
- Duplicate links, off-topic, and meta discussions may be moderated (locked or whatever the mods prefer)
- Post a link to the NEW articles thread.
As always, comments and suggestions welcome! The main goal is to keep the noise down. |
|
|
|
Locking this topic. Please post new press hits in the Press board. Create a new thread for each new story. |
|
|
|
"stmt.sharelog":"INSERT INTO shares (rem_host, username, our_result, upstream_result, reason, so$
That bit is certainly corrupted. |
|
|
|
|
You're just not gonna do it one musician at a time.
CoinDL needs to approach music clearinghouses, MP3.com and other entities that can offer a huge libraries of music. Because CoinDL is a startup, presumably you would have to give up a big cut of the per-download price, to avoid paying large up-front charges for such bulk library purchases.
|
|
|
|
|
run it in gdb, and use the "bt" command when a segfault occurs. Make sure to enable thread tracing, if that is not default / built in.
|
|
|
|
Given that CPU mining support has been discontinued for cgminer, I hope that people will find this fork useful.
Really? Maybe we should reactive jgarzik/cpuminer then. and start merging pull requests. |
|
|
|
|
Thanks to all our contributors and testers for their hard work.
|
|
|
|
Actually... I think we should re-think this. Why not just let them make up transactions? It seems that if they include any transactions (maybe needing to add up to a minimum amount) that this specific problem is solved.
That'd make things a little more difficult for botnet operators, but it can be bypassed. The botnet software could listen for blocks and transactions on the Bitcoin network and include them without checking them or storing them. The resulting blocks will usually be valid, since legitimate nodes don't relay bad transactions. The botnet could even "check" each transaction by seeing if its other peers either already have the new transaction or will accept it. I just realized that this attack also applies to other proposals requiring some amount of transactions from the memory pool to be in the next block. As long as they are including valid transactions, who cares if they have the entire block chain, or by what method they are selecting transactions to include in the block? Any invalid transaction inclusion will result in their hard work being wasted, as that block would be disregarded by all. Miners only get paid if the blocks are relayed, accepted, built upon. Picking random transactions seen since last block, without any validity checking, is a valid strategy, if inefficient and potentially costly. |
|
|
|
|
Personally, I favor a drastic rule such as
* Build a list of "likely to be in next block" transactions, from memory pool
* Do not relay blocks unless they contain at least 50% of the transactions in the "likely to be" list
This is "drastic" in my estimation because such a rule has notable downsides,
* Increases possibility of short term fork
* Creates de facto requirement that at least 50% of each block are standard transactions (as defined by isStandard)
* and some other minor fallout
However, it is a strong rule that does address the issue at hand, while permitting valid, no-tx-activity zero-transaction blocks to exist.
|
|
|
|
Why would a rational miner want to allow free tx forever?
To encourage users to use the network. A network's value increases as its userbase increases (and vice versa). |
|
|
|
There is no economic incentive to including txs.
Incorrect. Including transactions creates incentives for bitcoin users to use the network (faster transactions). Slower transactions discourage users from using the network. This is why deepbit includes as many transactions as it can, and doesn't really worry about fees too much. Deepbit wants to create incentives for bitcoin use. Too many no-tx blocks, and users will drift away, causing the value of each bitcoin to drop. Thus, in the short term, no-tx blocks may make money for the botnetter, but in the long run it will make their (and yours) bitcoins worth less. The value of bitcoin lies in the strength of the network, and the number of users. |
|
|
|
|
Show Posts
