|
>liquid nitrogen generator
Those don't even exist.
|
|
|
|
So you need two threads to scam? And you want me to post the same reponse in each one, ok. Now it is plainly obvious that you're a scammer and an extortionist as it is you who have stated posting in both of my threads. You clearly do not know what "scammer" and "extortionist" means. scammer = fail to uphold his side of the agreement extortionist = obtaining money through coercion So tell me, how exactly did buyer do any of the two things? |
|
|
|
|
It looks like a low quality chinese dropship website. Your best hope would be to buy the domain outright.
|
|
|
|
I find this story suspicious. - The alleged theft took place over 2 transactions, each over 10 hours apart. A thief wouldn't do this because it increases his chance of detection
- The alleged theft did not clean out OP's wallet. If you check blockexplorer, there are still funds left at his address. why a thief would leave $4 left at a victim's account is beyond me.
|
|
|
|
I may have a solution for consolidating micro transactions! Literally just came to me.
One Node Processing Multiple Dust Payments to One Person
Say John, Alice, and Kate all want to send microtransactions to Joe. Each one being 0.00000001 BTC. A Satoshi. (In this situation, the network blocks dust transactions of only 1 Satoshi, 2 would pass. This is simply an example.) Because of their low transactions, they won't get processed.
Solution? How about we bundle their transactions using Nodes? We could have a list of nodes set up and displayed somewhere here on the thread, where one could register to be added to the Node's "dustbook".
So if John, Alice, and Kate were to all register with Jacob's Node, when their Satoshi transactions are sent, the Node senses them all, rewrites them, and broadcasts it to the rest of the network as a reverse sendmany transaction to Joe. So the three of them basically bundled their addresses into one virtual "wallet" hosted by the Node only in the instance of the transaction totalling their virtual balance to 0.00000003 BTC, bypassing the 1 Satoshi dust limitation, and Joe gets their dust transactions.
The 1 Satoshi transactions wouldn't be displayed in the blockchain though. Their Satoshis would probably have to be sent directly to the node in some manner, where they then get rebroadcasted in one transaction. It's more efficient than having 3 transactions, and the dust value would go through.
To apply this to Bitcoin's current rules, just simply add more people and a slightly higher value to their transactions.
Graphical Representation:
1John -> JacobNode
1Alice -> JacobNode } JacobNode -> 1Joe
1Kate -> JacobNode
The transactions to JacobNode wouldn't show up in blockchain, but the transaction from the Node to Joe would. The transactions into the Node don't need to be broadcasted because the Node would be able to verify that the addresses have the Bitcoin in the first place because of the blockchain anyways.
Faucet Solution
1 Satoshi dust limit situation
Simply, a faucet would pool up a person's faucet earnings until they passed the dust limit. Or on the faucet site, implement a "Cash Out" button that only becomes available after the 1 Satoshi dust limit is passed.
what's the advantage of this over off-the-chain transactions? It's essentially what you're proposing. |
|
|
|
google kthx
Discussion is a beautiful thing.No, it's not "Discussion" when we're going over the same points over and over. It's just noise. If you can't show the courtesy of searching before posting, don't post. |
|
|
|
If you want to ensure you have the correct voltage reading you can try measuring it with a multimeter. Take one of the molex connectors and the black wire of the multimeter should go to the black wire of a molex connector and the red one should go with a yellow one. Picture below is not mine but that's how it should look:  Don't forget to measure the voltage both when the rig is idle as well as when it is under full load. if you're going to do that, make sure your multimeter's margin of error is less than +-0.1 volts. Because anything more and you're just measuring noise. Also, if you're on a mult-rail PSU, make sure you measure each rail. |
|
|
|
only problem: your rates are not competitive at all. You're essentially reselling OVH at 150% markup.  |
|
|
|
GPU mining with 7950 ( SEARCH for more details) |
|
|
|
Charge backs?
call credit card company, say the purchase is fraudulent,  , profit. As for in-game items, you might be able to do some ad-hoc trading for bitcoins. But you'll find buyers scarce because most game developers hold a monopoly on in game purchases. |
|
|
|
2FA and encrypted passphrases of sufficient strenght should be mandatory at resp. cloud wallets and local wallets.
in other words, everywhere. no shit. |
|
|
|
|
It's banned on apple app store, and probably on google play as well. Even if it's allowed, you'll still have to deal with the possibility of chargebacks.
|
|
|
|
Can you give a summary of what happened? because your story makes no sense. The address you mentioned received a 8.9 BTC transaction, then a 4.6 BTC transaction. None of the are close to 10 BTC. Note to moderators, please have this thread moved.
note to jaywaka2713, moderators are not omniscient and therefore can't see your request for the thread to be moved. |
|
|
|
Confirmation eta is based on the target difficulty the bitcoin software determines. The higher the difficulty, the longer the time between confirmations (on average). So by making confirmations happen twice as often (every 5 minutes or so, ideally), the security granted by that confirmation represents half the work to secure your money (because the confirmation is easier to get, and thus an attacker could potentially "luck out" and get a block that much easier. Perhaps if you don't know how the system works, you shouldn't propose changes to the fundamentals of bitcoin  So if I understand you correctly, the higher the difficulty, the longer the confirmation eta? Does this mean that confirmations will get infinitely longer as time progresses? lolwut. difficulty makes it harder to get a block, but higher hash rate makes it easier. In short, the two are designed to cancel out to provide a consistent block time. If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation).
Could you please provide a link to something explaining green addresses and off the chain tx? If you know enough about them, you are welcome to post here as well. I'd like to know more. google kthx https://en.bitcoin.it/wiki/Green_address |
|
|
|
Can we develop and run clients that can host nodes as well? Or would they be considered "cancer nodes"
Yes, you're free to do whatever you want with your node. But other nodes will only accept your blocks and your transactions if it agrees with their policy. Think of it this way: bitcoin is like free speech. You're free to say whatever you want, but everyone else has no obligation to listen to you. |
|
|
|
|
Will newbies destroy bitcointalk?
Yes, but only if they don't search.
|
|
|
|
I, a two year long Bitcoin user, have experienced the issues with the current 10 minute block time. There has been endless discussion about making zero-confirmation transactions safe, but what if a lighter solution is better? Why not reduce the block time? Now, I understand that a block time of 30 seconds does nothing but damage, and will not propose that, but what about a block time of 2 minutes? That will speed up transactions by 500%, and will make the hour-long transaction something of the past.
Hahahahha it doesn't work that way. Your transaction may confirm "faster", but it's in no way more secure. Not to mention all the extra orphans. If you want secure 0 confirmation transactions, there are plenty of solutions to that (green address, off the chain tx, risk mitigation). |
|
|
|
Yes.
If nOffset is 0 then fMatch is false and we get a warning.
No but check a few lines above that. It's a BOOST_FOREACH. Therefore, at least 1 peer has to have time in the open interval of (0, 5 minutes) for the warning not to trigger. Also, if you examine the outter if statement, you'll see a check of "if (abs64(nMedian) < 70 * 60)", Which means the check only triggers when that's false. |
|
|
|
|
Show Posts
