Pages:
Author

Topic: Wonder who this solominer is? 88.6.216.9 - page 20. (Read 60441 times)

legendary
Activity: 1386
Merit: 1003


If you're going this route, as a node, you could look at the number of transactions (maybe add up their fees) you have collected yourself from the network and require a certain percentage of that to be included in order for a given block to be accepted by you, say 20% for example. So if you have accumulated 20 transactions, a block would have to include at least 4 of these in order for you to accept it. This would guarantee the block to contain at least some fresh transactions.

I'm pretty sure this would have all kinds of implications and probably something prohibitive. It would certainly increase danger of chain-split.

I thought of this and posted it earlier in the thread with 10% minimum.  Unfortunately this can lead to splits if transactions are not properly relayed.  It probably wont happen often but it will happen.  Rules could be made to overcome this, but all of this adds complexity and the possibility of unknown results.   Having a minimum will just cause MM to include a repeating transaction or two of his own, not from the waiting list. 
donator
Activity: 2772
Merit: 1019
Can't we easily solve this problem by convincing all honest nodes to reject 1tx blocks?

If this happens, the MM has to include at least one other tx to make any BTC at all. This will force him to engineer some sort of solution to verifying transactions (supposedly he isn't verifying now due to the cost of managing the blockchain). Either he will give up or he'll start including transactions.

thoughts?
What happens when no one sends a transaction, and there are none to include? Why couldn't the miner include 1 or 2 txns of his own in each block to pad it out to the required minimum? TL;DR, NO. Won't work.

If you're going this route, as a node, you could look at the number of transactions (maybe add up their fees) you have collected yourself from the network and require a certain percentage of that to be included in order for a given block to be accepted by you, say 20% for example. So if you have accumulated 20 transactions, a block would have to include at least 4 of these in order for you to accept it. This would guarantee the block to contain at least some fresh transactions.

I'm pretty sure this would have all kinds of implications and probably something prohibitive. It would certainly increase danger of chain-split.
donator
Activity: 2772
Merit: 1019
... as it's that someone just discovered a massive breakthrough in software/hardware hashing and/or decided to invest massively in it.
I would like that a lot!
Very interesting idea to dream about, 1 GH/s on a normal CPU.

That dream only works if you're the only one, which apparently you are not. Doesn't matter how many PetaHashes we churn out on a CPU, the difficulty just eats the zeros.
rjk
sr. member
Activity: 448
Merit: 250
1ngldh
Can't we easily solve this problem by convincing all honest nodes to reject 1tx blocks?

If this happens, the MM has to include at least one other tx to make any BTC at all. This will force him to engineer some sort of solution to verifying transactions (supposedly he isn't verifying now due to the cost of managing the blockchain). Either he will give up or he'll start including transactions.

thoughts?
What happens when no one sends a transaction, and there are none to include? Why couldn't the miner include 1 or 2 txns of his own in each block to pad it out to the required minimum? TL;DR, NO. Won't work.
donator
Activity: 532
Merit: 501
We have cookies
Can't we easily solve this problem by convincing all honest nodes to reject 1tx blocks?

If this happens, the MM has to include at least one other tx to make any BTC at all. This will force him to engineer some sort of solution to verifying transactions (supposedly he isn't verifying now due to the cost of managing the blockchain). Either he will give up or he'll start including transactions.
Honest nodes can mine 1tx blocks too and it's normal in some cases.
hero member
Activity: 527
Merit: 500
Can't we easily solve this problem by convincing all honest nodes to reject 1tx blocks?

If this happens, the MM has to include at least one other tx to make any BTC at all. This will force him to engineer some sort of solution to verifying transactions (supposedly he isn't verifying now due to the cost of managing the blockchain). Either he will give up or he'll start including transactions.

thoughts?
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
If it's a botnet, perhaps it could be using an unknown SETI@Home/BOINC exploit or trojan?

or it is seti/boinc/folding itself... making a quick buck for marketing and driving people away from bitcoin back to scientific calcs.

(i don't really believe that  Tongue)



hard to believe given those projects do floating point operations in their software and use Nvidia GPUs
hero member
Activity: 1596
Merit: 502
... as it's that someone just discovered a massive breakthrough in software/hardware hashing and/or decided to invest massively in it.
I would like that a lot!
Very interesting idea to dream about, 1 GH/s on a normal CPU.
legendary
Activity: 1708
Merit: 1019
If it's a botnet, perhaps it could be using an unknown SETI@Home/BOINC exploit or trojan?

or it is seti/boinc/folding itself... making a quick buck for marketing and driving people away from bitcoin back to scientific calcs.

(i don't really believe that  Tongue)

donator
Activity: 980
Merit: 1000
That is much less likely.  Not unless large organizations are equipping fleets of machines with high end ATI video cards.  

Render farms? cyber cafe chain stores targeting gamers? what if someone developed a toolbar and paid affiliates for hashing? not including transactions to blocks is not against the law and may be not worth it for a big enough network, being fees typically as low as they are.

We have a couple distinct problems here:

1 - we don't know for sure what's going on. For my money it's as likely that 200k gamers don't realise that their computers are blasting their fans way too much, as it's that someone just discovered a massive breakthrough in software/hardware hashing and/or decided to invest massively in it.

2 - not including transactions properly is, in itself, not against the law. If the system is not evolutionarily stable towards including transactions, then that was that. I'm afraid that a 0.3% premium for including transactions doesn't seem to cut it.  "On the bright side", block reward will halven relatively soon and hopefully a bigger bitcoin economy will make this premium much bigger too.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Also since most transaction require 6 confirms even with 15% of blocks having no txs the average 6 confirm time only grows to 63 minutes vs 60 minutes.
hero member
Activity: 518
Merit: 500
the big problem here (for Bitcoin) is the fact that they are not accepting any transactions in their blocks.

Even if this botnet would achieve 50% of the hashrate, not including transactions will only slow down transactions by 50%, so 10 extra minutes for single confirmations. Not a huge problem when compared to that other potential of a 50% botnet.

I will say, it does suck that honest miners have to compete with stolen computing resources, but thats life. I just hope it wont drive up difficulty to the point were honest miners are driven out of the market. That could be a real problem for bitcoin. At least we would need some competition between botnets to keep them "honest" lol.
donator
Activity: 2772
Merit: 1019
If it's a botnet, perhaps it could be using an unknown SETI@Home/BOINC exploit or trojan?
Very clever. 

maybe someone @AMD managed to sneak in some clever firmware that can talk to an ethernet controller Wink
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
weather its a botnet or not it really does not matter

the big problem here (for Bitcoin) is the fact that they are not accepting any transactions in their blocks. It does not really matter if its a zombie botnet or a group of former KGB members with a ASIC farm humming in the basement of the Kremlin.

We need to put pressure on these folks any way we can, at least until the Bitcoin developers come up with a either a way to enforce transactions (not sure if this is even possible) or come up with some way to get rogue miners like this to want to accept them. Its obvious they care nothing about the Bitcoin network but they certainly care about making money and thats where we need to hit them.







legendary
Activity: 1386
Merit: 1003
If it's a botnet, perhaps it could be using an unknown SETI@Home/BOINC exploit or trojan?
Very clever. 
legendary
Activity: 1386
Merit: 1003
I doubt it's a botnet. To amass such hashing power with random computers you'd need the biggest botnet ever known.
As I have posted before, unfortunatly that is not true.  I wish it was.  Botnets have reached over a million computers.  Secondly, why must they be random?  Botnet owners do inventory their systems, and can sell off (or rent) groups of computers.  This is a selected group.

It's probably someone with legit access to these machines and therefore doing nothing wrong at all.

That is much less likely.  Not unless large organizations are equipping fleets of machines with high end ATI video cards.  
legendary
Activity: 2352
Merit: 1064
Bitcoin is antisemitic
I doubt it's a botnet. To amass such hashing power with random computers you'd need the biggest botnet ever known.

It could have easily targeted the gamers sharing some pirated games infested with trojans and whatever so to gain just the best hw.
legendary
Activity: 1666
Merit: 1000
Reminds me of our initial MM last year...

I think slush spoke to him IIRC...
donator
Activity: 362
Merit: 250
If it's a botnet, perhaps it could be using an unknown SETI@Home/BOINC exploit or trojan?
donator
Activity: 980
Merit: 1000
I doubt it's a botnet. To amass such hashing power with random computers you'd need the biggest botnet ever known.

It's probably someone with legit access to these machines and therefore doing nothing wrong at all.
Pages:
Jump to: