2. You may want to document the background URI encryptor. It's a new feature that was implemented in the latest mbc-toolkit. You can post your URI in the background and the SCI will return the encrypted version of the URI. I ended up using it on Bitcoin2CC to stop people who were trying to cheat my price calculator. It works perfectly. I wish other systems like LR had this feature. Pecunix and GlobalDigitalPay have a feature that permits validation of the input form. You hash the input fields, plus an API secret key. Totally eliminates tampering. I've long wished Liberty Reserve had a similar feature. |
|
|
|
More likely, many people will use a website such as mybitcoin rather than the bitcoin client. Each user then only has to worry about their login password, just like other banking websites. |
|
|
|
|
The P2P network needs to support SSL, for enhanced privacy.
|
|
|
|
|
Version 0.3.3 is out there, with a critical one-line fix for cryptopp_asm algo.
SHA1: a7c0822c3ab0f9f2089fbc65cdbe2506789e4241 cpuminer-installer-0.3.3.zip
MD5: 2df889eebf752b5f35293e4cbe53f7e8 cpuminer-installer-0.3.3.zip
|
|
|
|
So there is no way to handle the growth? This seems like a problem whether other stuff goes in or not.
Transaction fees. Whether the block chain is currency-only or currency+data, the result is the same: transaction fees rise as overall block size increases. More data == more expense (theoretically the block chain provides more value to more people, and is therefore more valuable) |
|
|
|
Merging bitcoin with some other completely unnecessary crap would be the worst idea of the century.
I would welcome a fork with open arms in such a situation.
If anybody wants to play, he should find himself a sandbox. We're doing serious buisness here, this is no place for toys.
Does a change need to be made to let this stuff in, or a change made to keep this stuff out? Can you tell me more about why it matters if a transaction has extra meaning to someone else. How will you even tell, won't it look like a normal transaction? Only legit transactions can get in, right? If someone wants to transmit arbitrary data, there is generally always a way. For example, data may be encoded today in a standard transaction, probably around 32 bits per transaction, simply by specifying an amount such as "0.12345678". However, that does not mean that we should encourage the use of additional, non-standard transaction types created for the express purpose of storing arbitrary data in the block chain. For example, it has always been possible to tunnel the IP protocol over DNS; but that does not mean it is wise to do so. No mainstream DNS server supports such behavior, even if the protocol itself does. Some BitDNS proposals here describe operations such as storing DNS records themselves in the block chain, where each IP address or nameserver change would be propagated throughout the bitcoin P2P network, and be stored in the local storage of all bitcoin full-block-chain P2P clients. |
|
|
|
Only a very few fallback nodes are persistent over time, and compiled (hardcoded) into the bitcoin client itself. https://en.bitcoin.it/wiki/Fallback_Nodes is a viable method of bootstrapping. We'll call that "forum bootstrapping" or "wiki bootstrapping", where one must manually search for a list of nodes, in order to bootstrap onto the network. I think DNS bootstrapping would be the most efficient: a simple DNS lookup to bootstrap.bitcoin.org would work like this: - Community members post their nameserver (NS) records for bootstrap.bitcoin.org on the forum. Presumably this list does not change often
- Each member runs a DNS server, independently of anyone else, that retrieves addresses from bitcoin's addr.dat database, randomly selects "fresh" P2P nodes, and stores these in A records or SRV records.
- When bootstrapping, the bitcoin client performs a standard DNS lookup for bootstrap.bitcoin.org
That would be very, very fast. Much faster than IRC. This is similar to how BitTorrent DHT bootstrapping occurs. The only issue is trust (rogue DNS servers), but this issue also exists with the IRC server, which is a Single Point of Failure (SPOF) for both trust and general reliability. |
|
|
|
aha, so in general any given block with the nonce as the only variable is not likely to have a solution at all?
It is always possible that there is no solution for the entire range of nonce (0 - 0xffffffff). However, the timestamp and extranonce are changed every few seconds, as is merkle tree root. This helps avoid a situation where we get stuck with no solutions. |
|
|
|
bitcoin maintains a database of P2P addresses. Obtaining addresses via netstat is rather sub-optimal, when you could use bitcointools to extract addresses directly from the bitcoin database. As to the larger point... HTTP and DNS bootstrapping should be pursued. Much more efficient than IRC. |
|
|
|
Hm.. Drupal coding standards are not hideous at all. As I understand, this code is public domain and I can take it, reformat or do anything to be accepted in drupal.org and put it under GPLv2+? If so I might consider to fork it and post it under my account. But for you to become co-maintainer you still need to apply for a CVS account on drupal.org.
CVS??? That's quite hideous. |
|
|
|
|
pastecoin got hacked, before I had a chance to review any of the code.
The Apache web server has been shut down until this is fixed.
|
|
|
|
Please fix your quoting  |
|
|
|
I think the problem for via is we have to move the (byte swapped) nonce back into the data_in parameter to return it.
Indeed. cpuminer 0.3.2 is out there, with another sha256_via fix attempt. Via CPU owners, please report feedback. |
|
|
|
Is the new owner doing anything with it?
Yes, but it is Christmas holidays right now. |
|
|
|
It seems there something wrong with the padlock code for the VIA Nano, at least in 64bit mode.
Are you using cpuminer? You need version 0.3.1 for sha256_via fixes. |
|
|
|
|
Yes, a TXT record would be much more appropriate than trying to cram data into network addresses.
|
|
|
|
|
There still needs to be an easy, standard way to associate a DNS name with a bitcoin address.
On a business card, you need something human readable like "donations.bitcoinwatch.com" that can be translated by software into a bitcoin address.
|
|
|
|
If one of the mining pool folks think this would be useful in a production miner, then I see the value. If it is only really useful if you're trying to debug a remote miner that isn't working quite right...
Right, and that's happened for all of the 'getwork' miners up to this point. This is a simple printf() patch that has actually proven useful in the field, not a speculative change with zero users. |
|
|
|
main.cpp? There's no such file in the cpuminer directory… "bitcoin patch" == a patch to bitcoin, not cpuminer. |
|
|
|
|
Show Posts
