in addition to hard-coded list, what do you think about my idea of having a convention of using for bootstrap a list of DNS names like
fallback.bitcoin.<tld> or bootstrap.bitcoin.<tld> for every known TLD, there are couple of hundreds of them.
Seems easier to abuse than just hardcoded trusted DNS names, where site owners proactively indicate interest in being listed. Long term, I hope some community members step up to - administer a domain bitseed.example.com
- use https://github.com/gavinandresen/bitcointools to dump bitcoin's address database
- select 5-6 "fresh" addresses on port 8333
- dynamically update your DNS bitseed.example.com to list those 5-6 addresses in A records
This sort of dynamic P2P sampling + export is preferred over simply listing long-running node jgarziks_node.example.com. |
|
|
|
|
This efficiency number is a bit misleading, IMO.
There is no guarantee that a solution exists in a 'getwork' data unit.
Better to rename "efficiency" as "luck." It is more clear.
|
|
|
|
URL: http://yyz.us/bitcoin/patch.bitcoin-dnsseedThis patch adds "-dnsseed" command line argument, which causes bitcoin to read P2P node addresses from DNS A records retrieved via lookups against a precompiled list of DNS names. Presumably, trusted community members running long-running nodes could list their nodes here. Also, someone might wish to create a service that examines current P2P addresses from addr.dat, and exports a random selection of fresh nodes via DNS. |
|
|
|
|
Call for hacking:
Anybody want to volunteer to add server failover support to cpuminer? (m0mchil's miner, too...)
Server failure should not interrupt mining [much], ideally.
|
|
|
|
I know that even asking this question may seem like heresy, but I'm curious. I think it's a fair question, the BTC community is mostly miners at this point, and press will inevitably bring more miners into the system. How does everybody feel about it?
Who says the BTC community is mostly miners? |
|
|
|
Would this payload "domainchain" proposes to use be stored in the block chain indefinitely? How big can the payload be and what is it's purpose in the protocol? Can nodes choose to ignore it?
AFAIK, BitDNS data will not be stored in Bitcoin main chain... i thought this is already clear. Under the plan by theymos, it would be stored in the bitcoin main chain. satoshi suggested an alternative, where there would be multiple bitcoin chains, and the non-currency data such as BitDNS would be stored there instead of the main chain. |
|
|
|
|
Fixed little endian is just fine, and happens to match 99.9% of our current usage.
Big endian adds pointless byteswapping. "network endian" is just so that Sun could sell more hardware, back in the day.
|
|
|
|
Old clients will refuse to relay sendmany transactions Using this way anyone with new client can doublespend money - send once to client with new version, then send second time to the client with old version. If someone confirm the second transaction (which is theoretically possible, while not everybody miner update their software), the money will be doublespent. I think you misunderstand the latitude miners are given. A block may only belong to the 'best' chain if its transaction inputs may be connected and verified. Thus, anyone who creates a block may create a non-standard transaction, but that transaction -- once it makes it into a block -- must still be verified by the same basic checks that guard against incorrect signatures, double-spending, etc. |
|
|
|
Is there anyway /anywhere i can get a simple list of transactions with just the data of sender/receiver/amount?
In bitcoin, one only knows (a) input addresses, (b) output addresses, and (c) amount. That tells you send, receiver and amount. |
|
|
|
Another feature we need IMO is the ability to reclaim payments that aren't going through, and/or to reissue payments with a higher transaction fee. (We also need basic support for transaction fees.) As the network gets busier this will become important.
+100 agreed. This should be a high priority, IMO. Here's my own, off-the-cuff, probably-wrong theory: Create transactions with a specified lifetime, either in wall clock time or number of confirmed blocks. If the transaction is not recorded in a block by the deadline (24 hours or 144 blocks?), all nodes will refuse to relay it and miners refuse to incorporate it, thus giving the user the opportunity to resend it with a proper fee. In general, transaction fees -- from a user perspective -- is still a bit opaque, and easy to get wrong. It would be nice to have deterministic behavior for transactions that are not incorporated immediately. |
|
|
|
|
Each miner should include code to fallback to a separate miner.
|
|
|
|
Eventually a botnet or two was bound to connect, see how poorly CPU mining pays, and disconnect.  |
|
|
|
Alternative clients strictly following official rules are wildly welcome (at least from me).
+1 agreed here, too |
|
|
|
This is true when those versions do something. Currently, we have many implementations where each does practically nothing. [...] writing YABNI from the scratch doesn't make sense for me.
Indeed. ArtForz' node implementation was posted over 3 months ago. I'll be interested once people can store and verify transactions and blocks, and handle a block chain switch. Until then... we have achieved 3x message encode/decode engines. Color me unexcited The best task for all these python programmers is a lightweight bitcoin client, one that only needs block headers, its own transactions and associated merkle branches. |
|
|
|
Probably because there's a whole JSON parser that's part of the miner...so might as well reuse the code!
Bingo. |
|
|
|
With a 10MB limit, someone can create 10 full blocks within a 500-block span to disable getblocks uploading for almost the entire network. This is probably an even more effective attack than whatever the limit is designed to protect against.
That won't disable getblocks uploading. But even so, the ideal would be to simply stop reading until the write buffer clears... |
|
|
|
I feel like send limiting is perhaps not that essential. If we really see BitCoin nodes OOMing because they tried to send data too fast that implies there's a bug elsewhere. For instance getdata requests have a size limit for exactly this kind of reason (it might be too large, but we can tweak that).
Ultimately, the goal is flow control. Your OS has a buffer for outgoing data. When that gets full, we need to stop sending more data, and wait for empty buffer space. The worst case buffer size of a hacker is zero. The worst case "normal" buffer size 8k. Since bitcoin needs to send more data than that in a single message, an implementation must choose: (a) store a pointer to the middle of the object you were sending, for later resumption of transfer, or (b) provide an application buffer that stores a copy of all outgoing data until it is transmitted. satoshi chose (b) but placed no limits on the size of that outgoing data buffer. It does sound like the limits are tighter than they should be. |
|
|
|
|
Show Posts
