Latest posts of: kjj

I got mine today too. Busily updating p2pcoin to run them.

Yes, ASICs have unfortunately ruined Bitcoin. If you're looking for security, use Litecoin.

Litecoin is not ASIC proof.

In technicality is is not. In reality it is. ASICs would be a poor way to attack any scrypt coin as they would be more expensive then just buying off the shelf GPU's to carry out the same attack and useless after.

As I see it, until the ASICs are more evenly held in the market, it is harder to do a 51% on LTC then on BTC. My hope is that ASICs will become more evenly distributed to the mining community. Right now they are in too few hands.

This is nonsense. What keeps litecoin from attracting ASICs is that litecoin is pointless, not some magic in scrypt. If litecoin ever gets to the point that people are actually using it for commerce, then ASICs will follow quickly.

Every time the price dips on the exchanges, a new batch of boogeyman-seeking posts escape the speculation board and end up here.

Not long ago, the preferred boogeyman was "the manipulator". This week, looks like ASICs are taking the heat. Next week, it'll be the Winkelvoss twins, or the NSA, or the flying spaghetti monster.

Einstein was wrong, compound interest isn't the most powerful force in the universe. That crown belongs to the insatiable hunger of the human mind for finding false causes for chaos.

Quote from: FrictionlessCoin on July 02, 2013, 05:50:57 PM

Two questions:

(1) Does Bitcoin allow transactions to go directly from one client to another circumventing the network? (Did they recently disable this?)

(2) Can a user capture a transaction and sent the transaction via a different means (i.e. email or http) and have the transaction activated (or submitted) on the bitcoin network at a later time?

There used to be a pay-to-IP mode, where your node would connect to the IP address, fetch a pubkey, and write a transaction to that key. That mode was removed because it was totally unsafe (no authentication).

At any rate, the raw transaction API makes it (relatively) easy to create transactions and pass them around using whatever means you prefer. As an example, I have created transactions on offline computers, printed them as barcodes, and scanned them in for broadcast to the network.

This is pretty useless in the simple case of A paying B. As others have pointed out, the transaction that hasn't been seen by the network is easily double-spendable. But it can be useful in more complicated applications.

Quote from: hazek on July 03, 2013, 11:50:52 AM

You know I really don't care if that's true. Because what I do know is that it's wasting time on a problem that we might have over spending vital time we don't have on a problem that we have RIGHT NOW which frustrates me to no end.

A CEO with his prioritization skills would have been fired long ago.

There is certainly room for honest disagreement here. One could argue that the lack of authentication for addresses and transactions is a problem right now, while the size of the blockchain does not appear to be a problem today, but might become one in the future.

At any rate, Gavin isn't a CEO, he is an engineer. The payment protocol is something that can surely be solved, while the solution to the blockchain size is unclear. You can hardly fault an engineer that wishes to solve a problem he knows he can solve in preference to a spinning his wheels on something vague.

Buy a UPS.

Clever programming simply cannot prevent corruption during a power loss. The filesystem guys have been working on the problem for like 50 years, and they all agree that you need to buy a UPS.

Quote from: hazek on July 03, 2013, 09:20:05 AM

Quote from: TierNolan on July 03, 2013, 09:18:11 AM

Quote from: hazek on July 03, 2013, 12:10:04 AM

He intends to solve a problem that was already solved by private companies by implementing it into the reference client

So, what are they working on?

An integrated secure invoice system. Something the functionality of which Bitpay and all the other similar platforms already offer.

I think your understanding of the payment protocol is incorrect.

Doing the math in BC is already painfully slow. It would be so much worse in pure PHP.

Each node does not need to seek out and download every fork, only ones that might matter.

Only shallow forks might become important, but they are also expensive to create. Deep forks are cheap, but will never win and can be ignored.

There is also a far less practical limit. The number of items in the input and output lists are specified using varint values, which max out at 2⁶⁴-1.

It is obviously difficult to imagine situations where that limit will matter, but it is the only limit that applies directly.

The order of the keys is important.

Code:

bitcoind createrawtransaction '[{"txid":"12af315cdba24e9fd070a7579135d5ade458b5e71008b0421dcc6bb8a795b3cb","vout":0,"scriptPubKey":"a9143d0277df5a51360d0b2d68bbbbf7ed784601f30587","redeemScript":"5221024e43b94cfcdc4c8bd4502d37c8745538f19972434d1c72cb23e9ca0454103ef62103f74a2c52d87c81c589775510ff1d6743f4ab2529a7206cc28762f1559d716ada2102b55624dd872a0b3db3cf053dacd2960cfe909db3a5405353f95631cfc297dda253ae"}]' '{"1Bjaewgk3bXujiJUqLcrkk7aKSS1f9kUV3":0.0095}'

bitcoind signrawtransaction '0100000001cbb395a7b86bcc1d42b00810e7b558e4add5359157a770d09f4ea2db5c31af120000000000ffffffff01f07e0e00000000001976a91475bed242e9b2cf5b4d45ef9f052be369067eae6888ac00000000' '[{"txid":"12af315cdba24e9fd070a7579135d5ade458b5e71008b0421dcc6bb8a795b3cb","vout":0,"scriptPubKey":"a9143d0277df5a51360d0b2d68bbbbf7ed784601f30587","redeemScript":"5221024e43b94cfcdc4c8bd4502d37c8745538f19972434d1c72cb23e9ca0454103ef62103f74a2c52d87c81c589775510ff1d6743f4ab2529a7206cc28762f1559d716ada2102b55624dd872a0b3db3cf053dacd2960cfe909db3a5405353f95631cfc297dda253ae"}]' '["KxfZ1HKs7PLxXo7gmjJVU3Chvcu6fPKzBt61MEGnNZCpG4LC6kQH"]'

Looks like someone already sent it back to you.

Hashing takes far less work than generating keypairs, and so far the bitcoin network has done something like 2⁷⁰ hashes in 4.5 years.

Rather than forking it into the background of your current session, you'd be better off setting up a config file and an init script.

I use slackware, so I wrote my own. You can probably find scripts for more popular distributions if you look. Here is an excerpt from my rc.bitcoind:

Code:

bitcoind_start() {
if [ -x $BINFILE ]; then
echo "Waiting for NTP before starting bitcoin..."
/usr/sbin/ntp-wait
echo "Starting bitcoind: $BINFILE"
sudo -u bitcoind $BINFILE -conf=$CONFFILE -pid=$PIDFILE -daemon -datadir=$DATADIR
fi
}

If you don't care about incoming connections, you don't need to forward any ports. If you do want incoming connections, open TCP port 8333 (or forward it).

Quote from: MrKain on June 28, 2013, 02:46:39 PM

I don't understand why this is an issue -

If ver 0.8.2 is a problem, why not use 0.8.1 ?

Or someone recompile the 0.8.2 source with the changes you want/dont want ..

As far as I can see, no one has a central authority to decide anything on bitcoin.

The p2p network continues to work regardless of version ..

or am I wrong ?

You don't even need to recompile, you just edit a text file and restart.

The problem is that some people don't want you to be able to change how your node acts. They don't want you to have the option to refuse to relay their crap.

That is the reason for all of the fuss. 0.8.2 puts the node operator in charge of the relay policy for their own node.

Basically, this is just a mechanism that miners can use to publish proof that they are working on one branch or the other. Other miners can then take it as an advisory and decide voluntarily to switch (or not).

I like it a lot more than the usual idea that pops up once a month. But I don't see it as being very useful, at least not for miners. There is no penalty for working on the unpopular side of a fork, and there may even be a reward.

But for users, it may be useful if a transaction they care about is only in one fork or the other because they would be able to see what fraction of the network (by hashing power) is building on top of that fork.

Quote from: TECHICENINE on June 28, 2013, 04:35:52 AM

who?

http://www.profitspi.com/symbol-search.aspx?s=TLDR

"
No Symbols found for this search, please change or broaden your search text and try again.
Symbol Description Stock Exchange
"

You are searching in the wrong place. Try here instead.

Quote from: cypherpunks on June 28, 2013, 03:44:49 AM

Ah, okay, well first I either misused or found a bug in the unspent ["address",...] command. It didn't work when I put brackets around a single address, but only with no brackets.

Second, the way this will work, nobody will ever have all the keys to redeem the transaction, they will be signed independently and only the signed transactions will be shared. So listunspent seems not to work in that case.

Is there any way I can glean this info from a bitcoind client? Or do I have to use something like the blockchain.info api to find unspent transactions for arbitrary multisig addresses?

Correct. listunspent is the list of transaction outputs that are spendable right now, by this node. This is not particularly useful for split key systems, but we don't have anything better so far.

I just tested it by sending 0.1 BTC to a multisig address, and it shows up instantly in listunspent.

Does your node actually know that address? Does it have enough keys to redeem transactions sent to it?

Sigh.

Cost of attack: 15% of the global block reward, until the end of time (currently ~$378,000 per week)
Reward per successful attack: some fraction (50%?) of a fraction (perhaps nearly 100%) of the transactions happening in a randomly located 8 block window, plus the mining reward from 8 blocks

For the low, low cost of only 15% of the network, you can reliably overturn transactions in 0.7952% of the blocks.

I hope you didn't lose too much sleep over this. I'm sure not going to.

Value isn't like the other things we measure. Time, weight and length all still exist when we stop measuring them. Value only exists at the moment of exchange, and even then only relative to the things being exchanged, and only for the parties doing the exchanging.