When copying the address to the clipboard, it is preceded by the prefix "bitcoin:" - in most cases, this just requires manual deletion of the prefix by the user when pasting into the Web form.
Can we have the handle removed, and only copy the address itself?
|
|
|
OP actually brings up a topic no one really cares about: Is current bitcoin ready for mainstream adoption in terms of security? The answer is NO.
Bitcoin is ready. It has not been hacked, while wealth worth many billions of dollars has been safely transacted over years. You are really asking are computers ready, and the answer is - it depends. Mine is.The one from the OP was not. Your question is like asking if dollars are ready. They do get stolen, right? Pickpocketed, scammed away, robbed, lost, burnt, stolen, whatever. Are our homes or pockets or banks ready for dollars and euros? It depends. Some of them are, some aren't.
|
|
|
Did you leave your door open during the nap? Seriously, start by identifying what you have downloaded in last 24-48 hrs. Also, some network activity software will tell you if stuff is being uploaded / downloaded from your system. Pay careful attention to network activity. They can't make use of your machine unless they send stuff to / from it Technically, you cannot trust the potentially infected machine to monitor and report the network traffic. You need is of these:
|
|
|
Live is dead, so:
|
|
|
Look at this guys. WTF?? Have you tried trading? I am seeing {"result":"success","return":{"lag":0,"lag_secs":0,"lag_text":"idle","length":0}}
No problems whatsoever. Besides, your title is misleading: spam trades are not the same as ddos.
|
|
|
What I know at the moment: 0,18u-0,13u (180nm-130nm) with less than $250k (ASIC development $150k, shattle first test (50 chips) - $40k, chip assembling and final testing $40k) Development could take 3-4 months, maybe 5. You'll be way behind the game with that process and such lead time. Way behind using what metric? All ASICS currently being sold are expensive in terms of $s/hash, not J/hash. We cannot tell who is "way behind" until we see the price of finished product. But I am getting ahead of myself, since there is really nothing to be discussed in this thread yet, anf there won't be until the first unit is tested by an independent party.
|
|
|
I'm still feeling somewhat uneasy about Terrahash.
We have
The facts so far: - They hide website registering details behind a Privacy registrar; why would an officially registered company do that: Registrant: TerrHash, Inc. c/o Dynadot Privacy PO Box 701 San Mateo, CA 94401 United States
Note "TerrHash" in the official record. Maybe just a typo, if these are manually typed.
|
|
|
Are your products going to be declared as "made in the usa" for NAFTA purposes?
|
|
|
I am sorry to say, but it not user friendly at all. Keeping track of so many addresses can be a real pain especially if I am a successful shop with 10 - 100 transaction a day. It seems that bitcoin is not suitable for large scale # of transactions.
Large scale implies you are serious about your business. This implies proper effort related to accounting, supply chain management, legal, IT, and - yes - Bitcoin infrastructure. What you are complaining about is trivial, to say the least. Get serious or get out.
|
|
|
I hope this is clear by now: the only way to change the future supply of your coins from the schedule we have today is if YOU change it. Nobody can change it without your consent. Sure, they can change the supply of their coins, just like you could yours. This is what forks and consensus are all about.
|
|
|
Question about the idea Sounds like the engraved encrypted key will be too small to be able to read with the human eye? So in addition to the diamond and the password to decrypt the key, what would be required to access the btc account - ? A magnifying glass? a Microsope? Thanks and sorry if I missed the answer in a previous post! If cut in a certain way, you could just shine light through it and project the key onto the wall.
|
|
|
You cannot stress enough the durability of diamond as a material. Laser-engraved private key on diamond is likely to survive pretty much anything. I think this idea might work if Bitcoin grows more, and if it is marketed to the right group. Right now, you target would be wealthy (who appreciate diamonds) nerds (who appreciate Bitcoin), which is a rather slim intersection.
|
|
|
Outputs have scripts, not addresses. Not sure how this relates to the question of (non)existence of "from" addresses. And the recognition that transactions have lists of inputs and outputs should give you pause before thinking that you can connect an output to an input, in general.
Again, nothing to do with the issue discussed here. I never mentioned connecting an output to an input in the same transaction (the sum total needs to match, including miner's fees, that is all - no point connecting particular inputs to particular outputs). We agree there, but it is irrelevant. The first one seems to be a multisig attempt from 35nGJpcQr4pYVyFVR3BPbdaWUSk6NBryUD, discussed here.The second one clearly lists all addresses associated with (many) inputs. These are the "from" addresses. It's quite simple, can't we agree on this? OP was asking about "from" addresses, but was told there was no such thing in Bitcoin. I claim this is false, as transaction inputs specify public keys which translate into corresponding addresses. The coins are thus sent from these addresses, in the sense that control (ownership) of coins is reassigned from these "from" addresses (and the corresponding key pairs) to the receiveing addresses (and the corresponding key pairs).
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work. I think you are taking some metaphors too literally. I think there such thing as "from" address(es), and we can see them for any given transaction. Well, as long as you don't mind being wrong, you are free to keep thinking that. Explain how this is wrong: every transaction (other than generation-only) includes the public key of the payer (and the ECDSA signature using the corresponding private key of the payer). Payer's public key is thus revealed, and "from" address is simply the RIPEMD-160(SHA-256(PubKey)). Explicit example: Of course, if there are multiple inputs, there will be multiple "from" addresses.
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work. I think you are taking some metaphors too literally. I think there such thing as "from" address(es), and we can see them for any given transaction.
|
|
|
It's gone. I wonder how many downloads happened...
|
|
|
Getpeerinfo will do what it says. Peers.dat file contains much more, but I don't know how to read it.
|
|
|
The short version is that coins don't "come from" anywhere. If you look at your coins, you can do a little detective work and try to figure out the last place they went to before they went to your wallet. But when they came to your wallet, they didn't come from that place.
And that is for simple transactions, it can get worse.
Coins come from tx inputs, and go into tx outputs. If coins "don't come from anywhere," there is no way for any node to validate a transaction, and Bitcoin doesn't work.
|
|
|
|