BEWARE! μTorrent Silently Installing Bitcoin Mining Software

Transcript of Open Developer Meeting in Discord - 7/19/2019

[Dev-Happy] BlondfrogsLast Friday at 3:58 PM
Hey everyone. The channel is now open for the dev meeting.
LSJI07 - MBITLast Friday at 3:58 PM
Hi
TronLast Friday at 3:59 PM
Hi all!
JerozLast Friday at 3:59 PM
:wave:
TronLast Friday at 3:59 PM
Topics: Algo stuff - x22rc, Ownership token for Restricted Assets and Assets.
JerozLast Friday at 4:00 PM
@Milo is also here from coinrequest.
MiloLast Friday at 4:00 PM
Hi :thumbsup:
Pho3nix Monk3yLast Friday at 4:00 PM
welcome, @Milo
TronLast Friday at 4:00 PM
Great.
@Milo Was there PRs for Android and iOS?
MiloLast Friday at 4:01 PM
Yes, I've made a video. Give me a second I'll share it asap.
JerozLast Friday at 4:02 PM
I missed the iOS one.
MiloLast Friday at 4:02 PM
Well its 1 video, but meant for all.
JerozLast Friday at 4:02 PM
Ah, there's an issue but no pull request (yet?)
https://github.com/RavenProject/ravenwallet-ios/issues/115
[Dev-Happy] BlondfrogsLast Friday at 4:03 PM
nice @Milo
MiloLast Friday at 4:04 PM
Can it be that I have no video post rights?
JerozLast Friday at 4:05 PM
In discord?
MiloLast Friday at 4:05 PM
yes?
[Dev-Happy] BlondfrogsLast Friday at 4:05 PM
just a link?
JerozLast Friday at 4:05 PM
Standard version has a file limit afaik
Pho3nix Monk3yLast Friday at 4:05 PM
try now
gave permissions
MiloLast Friday at 4:05 PM
it's not published yet on Youtube, since I didn't knew when it would be published in the wallets
file too big. Hold on i'll put it on youtube and set it on private
LSJI07 - MBITLast Friday at 4:06 PM
no worries ipfs it...:yum:
Pho3nix Monk3yLast Friday at 4:06 PM
ok, just send link when you can
[Dev-Happy] BlondfrogsLast Friday at 4:07 PM
So guys. We released Ravencoin v2.4.0!
JerozLast Friday at 4:08 PM
If you like the code. Go update them nodes! :smiley:
[Dev-Happy] BlondfrogsLast Friday at 4:08 PM
We are recommending that you are upgrading to it. It fixes a couple bugs in the code base inherited from bitcoin!
MiloLast Friday at 4:08 PM
https://www.youtube.com/watch?v=t\_g7NpFXm6g&feature=youtu.be
sorry for the hold up
YouTube
Coin Request
Raven dev Gemiddeld
LSJI07 - MBITLast Friday at 4:09 PM
thanks short and sweet!!
KAwARLast Friday at 4:10 PM
Is coin request live on the android wallet?
TronLast Friday at 4:10 PM
Nice video.
It isn't in the Play Store yet.
Pho3nix Monk3yLast Friday at 4:10 PM
Well, this is the first time in a while where we have this many devs online. What questions do y'all have?
LSJI07 - MBITLast Friday at 4:11 PM
Algo questions?
Pho3nix Monk3yLast Friday at 4:11 PM
sure
KAwARLast Friday at 4:11 PM
KK
LSJI07 - MBITLast Friday at 4:12 PM
what are the proposed 22 algos in x22r? i could only find the original 16 plus 5 on x21.
TronLast Friday at 4:12 PM
Likely the 5 from x21 and find one more.
We need to make sure they're all similar in time profile.
liqdmetalLast Friday at 4:14 PM
should we bother fixing a asic-problem that we dont know exists for sure or not?
TronLast Friday at 4:14 PM
That's the 170 million dollar question.
[Dev-Happy] BlondfrogsLast Friday at 4:14 PM
I would prefer to be proactive not reactive.
imo
JerozLast Friday at 4:14 PM
same
LSJI07 - MBITLast Friday at 4:15 PM
RIPEMD160 is a golden oldie but not sure on hash speed compared to the others.
liqdmetalLast Friday at 4:15 PM
in my mind we should focus on the restricted messaging etc
Sevvy (y rvn pmp?)Last Friday at 4:15 PM
probably won't know if the action was needed until after you take the action
liqdmetalLast Friday at 4:15 PM
we are at risk of being interventionistas
acting under opacity
TronLast Friday at 4:15 PM
Needs to spit out at least 256 bit. Preferably 512 bit.
LSJI07 - MBITLast Friday at 4:15 PM
ok
TronLast Friday at 4:15 PM
If it isn't 512 bit, it'll cause some extra headache for the GPU mining software.
liqdmetalLast Friday at 4:16 PM
i seek to avoid iatrogenics
TronLast Friday at 4:16 PM
Similar to the early problems when all the algos except the first one were built for 64-bytes (512-bit) inputs.
Had to look that one up. TIL iatrogenics
JerozLast Friday at 4:17 PM
I have to google most of @liqdmetal's vocabulary :smile:
liqdmetalLast Friday at 4:17 PM
@Tron tldr: basically the unseen, unintended negative side effects of the asic "cure"
Sevvy (y rvn pmp?)Last Friday at 4:18 PM
10 dolla word
liqdmetalLast Friday at 4:19 PM
we need a really strong case to intervene in what has been created.
TronLast Friday at 4:19 PM
I agree. I'm less concerned with the technical risk than I am the potential split risk experienced multiple times by Monero.
Sevvy (y rvn pmp?)Last Friday at 4:20 PM
tron do you agree that forking the ravencoin chain presents unique risks compared to other chains that aren't hosting assets?
JerozLast Friday at 4:21 PM
Yes, if you fork, you need to figure out for each asset which one you want to support.
Sevvy (y rvn pmp?)Last Friday at 4:21 PM
yeah. and the asset issuer could have a chain preference
TronLast Friday at 4:22 PM
@Sevvy (y rvn pmp?) Sure. Although, I'd expect that the asset issuers will be honor the assets on the dominant chain. Bigger concern is the branding confusion of multiple forks. See Bitcoin, Bitcoin Cash, Bitcoin SV for an example. We know they're different, but do non-crypto folks?
Hans_SchmidtLast Friday at 4:22 PM
I thought that the take-away from the recently published analyses and discussions was that ASICs for RVN may be active, but if so then they are being not much more effective than GPUs.
Sevvy (y rvn pmp?)Last Friday at 4:22 PM
agreed on all accounts there tron
TronLast Friday at 4:23 PM
I'm not yet convinced ASICs are on the network.
KAwARLast Friday at 4:23 PM
It would be better to damage an asic builder by forking after they made major expenses. Creating for them the type of deficit that could be negated by just buying instead of mining. Asic existence should be 100 percent confirmed before fork.
liqdmetalLast Friday at 4:23 PM
170million dollar question is right.lol
TronLast Friday at 4:24 PM
I've had someone offer to connect me to the folks at Fusion Silicon.
Sevvy (y rvn pmp?)Last Friday at 4:25 PM
yes. and if they are active on the network they are not particularly good ASICs
which makes it a moot point probably
TronLast Friday at 4:26 PM
The difficult part of this problem is that by the time everyone agrees that ASICs are problematic on the network, then voting the option in is likely no longer an option.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
yes. part of me wonders if we would say "okay, the clock on the asic countdown is reset by this new algo. but now the race is on"
[Dev-Happy] BlondfrogsLast Friday at 4:26 PM
There are always risks when making a change that will fork the network. We want wait to long though, as tron said. It wont be a voting change. it will be a mandatory change at a block number.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
acknowledge the inevitable
MiloLast Friday at 4:27 PM
I had just a small question from my side. When do you think the android version would be published, and do you maybe have a time-frame for the others?
TronLast Friday at 4:27 PM
Quick poll. How would everyone here feel about a BIP9 option - separate from the new features that can be voted in?
KAwARLast Friday at 4:27 PM
Maybe voting should not be a strictly blockchain vote. A republic and a democratic voice?
[Dev-Happy] BlondfrogsLast Friday at 4:27 PM
@Milo We can try and get a beta out next week, and publish soon after that.
MiloLast Friday at 4:28 PM
@[Dev-Happy] Blondfrogs :thumbsup::slight_smile:
[Dev-Happy] BlondfrogsLast Friday at 4:28 PM
BIP9 preemptive vote. I like it.
TronLast Friday at 4:30 PM
The advantage to a BIP9 vote is that it puts the miners and mining pools at a clear majority before activation.
LSJI07 - MBITLast Friday at 4:30 PM
Centralisation is inevitable unless we decide to resist it. ASIC's are market based and know the risks and rewards possible. A key step in resisting is sending a message. An algo change to increase asic resistance is imho a strong message. A BIP9 vote now would also be an indicator of bad actors early....
TronLast Friday at 4:30 PM
The disadvantage is that it may not pass if the will isn't there.
LSJI07 - MBITLast Friday at 4:30 PM
Before assets are on main net and cause additional issues.
KAwARLast Friday at 4:31 PM
I am not schooled in coding to have an educated voice. I only understand social problems and how it affects the economy.
SpyderDevLast Friday at 4:31 PM
All are equal on RVN
TronLast Friday at 4:31 PM
It is primarily a social problem. The tech change is less risky and is easier than the social.
LSJI07 - MBITLast Friday at 4:32 PM
All can have a share....people who want more of a share however pay for the privilege and associated risks.
KAwARLast Friday at 4:33 PM
Assets and exchange listings need to be consistent and secure.
brutoidLast Friday at 4:36 PM
I'm still not entirely clear on what the overall goal to the algo change is? Is it just to brick the supposed ASICs (unknown 45%) which could still be FPGAs as seen from the recent block analysis posted in the nest. Is the goal to never let ASICs on? Is it to brick FPGAs ultimately. Are we making Raven strictly GPU only? I'm still unclear
LSJI07 - MBITLast Friday at 4:37 PM
What about the future issue of ASICs returning after a BIP9 fork "soon"? Are all following the WP as a community? i.e asic resistant or are we prepared to change that to asic resistant for early coin emission. Ideally we should plan for the future. Could the community make a statement that no future algo changes will be required to incentivise future public asic manufacturers?
Lol. Same question @brutoid
brutoidLast Friday at 4:37 PM
Haha it is
You mind-beamed me!
[Dev-Happy] BlondfrogsLast Friday at 4:38 PM
The is up to the community.
Currently, the feel seems like the community is anti asic forever.
The main issue is getting people to upgrade.
KAwARLast Friday at 4:38 PM
Clarity is important. Otherwise we are attacking windmills like Don Quixote.
brutoidLast Friday at 4:39 PM
I'm not getting the feeling of community ASIC hate if the last few weeks of discussion are anything to go by?
Hans_SchmidtLast Friday at 4:39 PM
A unilateral non-BIP9 change at a chosen block height is a serious thing, but anti-ASIC has been part of the RVN philosophy since the whitepaper and is therefore appropriate for that purpose.
[Dev-Happy] BlondfrogsLast Friday at 4:39 PM
We can use the latest release as an example. It was a non forking release, announced for 2 weeks. and only ~30% of the network has upgraded.
TronLast Friday at 4:39 PM
@Hans_Schmidt Well said.
liqdmetalLast Friday at 4:40 PM
I'm not concerned about a "asic hardware problem" so much as I believe it more likely what we are seeing is several big fish miners (perhaps a single really big fish). For now I recommend standing pat on x16r. In the future I can see an algo upgrade fork to keep the algo up to date. If we start fighting against dedicated x16r hashing machines designed and built to secure our network we are more likely to go down in flames. The custom SHA256 computers that make the bitcoin the most secure network in existence are a big part of that security. If some party has made an asic that performs up to par or better than FPGA or GPU on x16r, that is a positive for this network, a step towards SHA256 security levels. It is too bad the community is in the dark regarding their developments. Therefore I think the community has to clarify its stance towards algorithm changes. I prefer a policy that will encourage the development of mining software, bitstreams and hardware by as many parties as possible. The imminent threat of ALGO fork screws the incentive up for developers.
JerozLast Friday at 4:40 PM
@brutoid the vocal ones are lenient towards asics, but the outcome of the 600+ votes seemed pretty clear.
brutoidLast Friday at 4:40 PM
This is my confusion
TronLast Friday at 4:41 PM
More hashes are only better if the cost goes up proportionally. Machines that do more hashes for less $ doesn't secure the network more, and trends towards centralization.
JerozLast Friday at 4:41 PM
I would argue for polling ever so often as it certainly will evolve dynamically with the state of crypto over time.
TronLast Friday at 4:41 PM
Measure security in two dimensions. Distribution, and $/hash.
liqdmetalLast Friday at 4:41 PM
and volume of hash
traysiLast Friday at 4:42 PM
45% of the hashrate going to one party is unhealthy, and standing pat on x16r just keeps that 45% where it is.
TronLast Friday at 4:42 PM
Volume doesn't matter if the cost goes down. For example, lets say software shows up that does 1000x better than the software from yesterday, and everyone moves to it. That does not add security. Even if the "difficulty" and embedded hashes took 1000x more attempts to find.
brutoidLast Friday at 4:42 PM
My issue is defintely centralization of hash and not so much what machine is doing it. I mine with both GPU and FPGA. Of course, the FPGAs are not on raven
TJayLast Friday at 4:44 PM
easy solution is just to replace a few of 16 current hash functions, without messing with x21r or whatever new shit
TronLast Friday at 4:44 PM
How do folks here feel about allowing CPUs back in the game?
traysiLast Friday at 4:44 PM
Botnets is my concern with CPUs
brutoidLast Friday at 4:44 PM
Botnets is my concern
SpyderDevLast Friday at 4:44 PM
Yes please.
LSJI07 - MBITLast Friday at 4:44 PM
the poll votes seem not very security conscious. More of day miners chasing profits. I love them bless! Imho the future is bright for raven, however these issues if not sorted out now will bite hard long term when asset are on the chain and gpu miners are long gone.....
ZaabLast Friday at 4:45 PM
How has the testing of restricted assets been on the test net?
liqdmetalLast Friday at 4:45 PM
Agreed. I dont think x16r is obsolete like that yet however
[Dev-Happy] BlondfrogsLast Friday at 4:45 PM
@Zaab not enough testing at the moment.
HedgerLast Friday at 4:45 PM
Yes, how is the Testing going?
justinjjaLast Friday at 4:45 PM
Like randomX or how are cpus going to be back in the game?
TronLast Friday at 4:45 PM
@Zaab Just getting started at testing at the surface level (RPC calls), and fixing as we go.
ZaabLast Friday at 4:45 PM
And or any updates on the review of dividend code created by the community
Lokar -=Kai=-Last Friday at 4:45 PM
if the amount of hash the unknown pool has is fixed as standarderror indicated then waiting for the community of FPGAers to get onto raven might be advantageous if the fork doesn't hurt FPGAs.
ZaabLast Friday at 4:45 PM
Can't rememeber who was on it
SpyderDevLast Friday at 4:45 PM
@Zaab But we are working on it...
Lokar -=Kai=-Last Friday at 4:46 PM
more hash for votes
JerozLast Friday at 4:46 PM
@Maldon is, @Zaab
TronLast Friday at 4:46 PM
@Zaab There are unit tests and functional tests already, but we'd like more.
[Dev-Happy] BlondfrogsLast Friday at 4:46 PM
@Zaab Dividend code is currently adding test cases for better security. Should have more update on that next meeting
KAwARLast Friday at 4:46 PM
Absolute democracy seems to resemble anarchy or at least civil war. In EVE online they have a type of community voice that get voted in by the community.
ZaabLast Friday at 4:46 PM
No worries was just curious if it was going as planned or significant issues were being found
Obviously some hiccups are expected
More testing is always better!
TronLast Friday at 4:47 PM
Who in here is up for a good civil war? :wink:
ZaabLast Friday at 4:47 PM
Tron v Bruce. Celebrity fight night with proceeds to go to the RVN dev fund
SpyderDevLast Friday at 4:48 PM
Cagefight or mudpit?
JerozLast Friday at 4:48 PM
talking about dev funds..... :wink:
Pho3nix Monk3yLast Friday at 4:49 PM
and there goes the conversation....
KAwARLast Friday at 4:49 PM
I am trying to be serious...
ZaabLast Friday at 4:49 PM
Sorry back to the ascii topic!
traysiLast Friday at 4:49 PM
@Tron What do we need in order to make progress toward a decision on the algo? Is there a plan or a roadmap of sorts to get us some certainty about what we're going to do?
LSJI07 - MBITLast Friday at 4:50 PM
Could we have 3 no BIP9 votes? No1 Friendly to asics, retain status quo. No2 change to x17r minimal changes etc, with no additional future PoW/algo upgrades. No3. Full Asic resistance x22r and see what happens...
:thonk~1:
Sounds messy....
TronLast Friday at 4:51 PM
Right now we're in research mode. We're building CNv4 so we can run some metrics. If that goes well, we can put together x22rc and see how it performs. It will likely gore everyone's ox. CPUs can play, GPUs work, but aren't dominant. ASICs VERY difficult, and FPGAs will have a tough time.
ZaabLast Friday at 4:51 PM
Yeah i feel like the results would be unreliable
TronLast Friday at 4:51 PM
Is this good, or do we lose everyone's vote?
PlayHardLast Friday at 4:52 PM
Fpga will be dead
Lokar -=Kai=-Last Friday at 4:52 PM
why isn;t a simple XOR or something on the table?
ZaabLast Friday at 4:52 PM
The multiple bip9 that is
Lokar -=Kai=-Last Friday at 4:52 PM
something asic breaking but doesn't greatly complicate ongoing efforts for FPGA being my point.
justinjjaLast Friday at 4:52 PM
How are you going to vote for x22rc?
Because if by hashrate that wouldn't pass.
traysiLast Friday at 4:52 PM
Personally I like the idea of x22rc but I'd want to investigate the botnet threat if CPUs are allowed back in.
TronLast Friday at 4:52 PM
XOR is on the table, and was listed in my Medium post. But, the social risk of chain split remains, for very little gain.
traysiLast Friday at 4:53 PM
@Lokar -=Kai=- A small change means that whoever has 45% can probably quickly adapt.
LSJI07 - MBITLast Friday at 4:53 PM
Research sounds good. x22rc could be reduce to x22r for simplicity...
TronLast Friday at 4:53 PM
x22r is a viable option. No CNv4.
LSJI07 - MBITLast Friday at 4:53 PM
Don't know how much time we have to play with though...
Lokar -=Kai=-Last Friday at 4:53 PM
if they have FPGAs yes if they have ASIC then not so much, but I guess that gets to the point, what exactly are we trying to remove from the network?
PlayHardLast Friday at 4:54 PM
Guys my name is Arsen and we designed x16r fpga on bcus. Just about to release it to the public. I am buzzdaves partner.
Cryptonight
Will kill us
But agreed
Asic is possible on x16r
And you dont need 256 core
Cores
traysiLast Friday at 4:55 PM
Hi Arsen. Are you saying CN will kill "us" meaning RVN, or meaning FPGA?
JerozLast Friday at 4:55 PM
This is what im afraid of ^ an algo change killing FPGA as I have the feeling there is a big fpga community working on this
PlayHardLast Friday at 4:55 PM
Fpgas ))
whitefire990Last Friday at 4:55 PM
I am also about to release X16R for CVP13 + BCU1525 FPGA's. I'm open to algo changes but I really don't believe in CPU mining because of botnets. Any CNv4 shifts 100% to CPU mining, even if it is only 1 of the 22 functions.
Lokar -=Kai=-Last Friday at 4:55 PM
namely FPGAs that aren;t memory equipped
like fast mem
not ddr
PlayHardLast Friday at 4:55 PM
Hbm non hbm
Cryptonight
whitefire990Last Friday at 4:56 PM
Right now with both Buzzdave/Altered Silicon and myself (Zetheron) about to release X16R for FPGA's, then the 45% miner's share will decrease to 39% or less.
PlayHardLast Friday at 4:56 PM
Will be dead for fpga
LSJI07 - MBITLast Friday at 4:56 PM
sound so x22r is fpga "friendly" ... more so than asic anyway...
PlayHardLast Friday at 4:56 PM
But a change must be planned
X16r is no way possible to avoid asics
TJayLast Friday at 4:56 PM
@LSJI07 - MBIT I would say less friendly...
whitefire990Last Friday at 4:57 PM
As I mentioned in thenest discussion, asic resistance increases with the square of the number of functions, so X21R is more asic resistant than X16R, but both are pretty resistant
PlayHardLast Friday at 4:58 PM
Yeah more algos make it heavier on ASIC
DirkDiggler (Citadel Architect)Last Friday at 4:58 PM
My interpretation of the whitepaper was that we used x16r as it was brand new (thus ASIC resistant), and that was to ensure a fair launch... We've launched... I don't like the idea of constantly forking to avoid the inevitable ASICs.
x16r was a great "experiment" before we had any exchange listings... that ship has sailed though... not sure about all these x22rs lmnop changes
KAwARLast Friday at 5:00 PM
I believe that it is easier to change the direction of a bicycle than an oil tanker. We feel more like a train. We should lay out new tracks and test on them and find benefits that are acceptable to everyone except train robbers. Then open the new train station with no contentious feelings except a silently disgruntled minority group. ???
Hans_SchmidtLast Friday at 5:01 PM
The most productive action the community can do now re ASICs is to voice support for the devs to make a non-BIP9 change at a chosen block height if/when the need is clear. That removes the pressure to act rashly to avoid voting problems.
LSJI07 - MBITLast Friday at 5:01 PM
Thats why im proposing to fork at least once to a more asic resistant algo (but FPGA "friendly/possible"), with the proviso ideally that no more PoW algo forks are require to provide future ASICs some opportunity to innovate with silicon and efficiency.
TJayLast Friday at 5:01 PM
folks should take into account, that high end FPGAs like BCU1525 on x16r can't beat even previous gen GPUs (Pascal) in terms of hash cost. so they aren't a threat to miners community
PlayHardLast Friday at 5:02 PM
A proper change
Requires proper research
eyz (Silence)Last Friday at 5:02 PM
Just so I'm clear here, we are trying to boot ASICS, don't want CPUs because of Botnets, and are GPU and FPGA friendly right?
PlayHardLast Friday at 5:02 PM
It is not a quick one day process
eyz (Silence)Last Friday at 5:02 PM
If there is a bip9 vote there needs to be a clear explanation as I feel most in the community don't understand exactly what we are trying to fix
TronLast Friday at 5:03 PM
@Hans_Schmidt I like that route. It has some game theoretics. It gives time for miners to adapt. It is only used if needed. It reduces the likelihood of ASICs dominating the network, or even being built.
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Hey guys. great convo. We are of course looking to do the best thing for the community and miner. We are going to be signing off here though.
justinjjaLast Friday at 5:03 PM
TJay that comes down to power cost.
If your paying 4c/kw gpus all the way.
But if your a home miner in europe an fpga is your only chance
LSJI07 - MBITLast Friday at 5:03 PM
@Hans_Schmidt How do we decide the block limit and when sufficient evidence is available? I would say we have had much compelling information to date...
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Thanks for participating. and keep up the good work :smiley:
Have a good weekend.
CAWWWW
TronLast Friday at 5:03 PM
I haven't seen any compelling evidence of ASICs - yet.
Pho3nix Monk3yLast Friday at 5:03 PM
:v:
JerozLast Friday at 5:04 PM
I suggest to continue discussion in #development and #thenest :smiley:
thanks all!
TronLast Friday at 5:04 PM
Cheers everyone!
KAwARLast Friday at 5:04 PM
Agree with Hans.
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
thanks Tron
Pho3nix Monk3yLast Friday at 5:04 PM
Ending here. continue in Nest if wanted
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
I am waiting for compelling evidence myself.
submitted by mrderrik to Ravencoin [link] [comments]

Blockchain to fix horribly broken e-mail system like it is today?

E-mail as it is, is horribly broken. Horrendously broken.
It wasn't that many years ago that you could be assured your e-mail reaches whoever you were mailing to. Today it is a mere suggestion, that perhaps this should be delivered to this person, at least for any automated e-mail. This seems to be creeping to manual, organic email as well. Hell, we are seeing even internal e-mails being flagged by spamassassin as spam, organic, human written conversations! In that instance, the spamassassin is also maintained by one of the largest hosting providers in the world...
Hotmail/MS services has been for years (atleast about 4 years now!) been silently dropping email, not all, but some. There's a bit of relief lately, as they have started to favor a bit more marking as spam, rather than silently dropping.
I know, most email users don't see this problem, but those who use email a lot to do their work, and those who need to send automated emails (say, welcome e-mails for a service) this is a big problem. (Disclaimer, for us, our niche of hosting probably causes flagging as well. Our site is blocked by many corporate firewalls for example)
Blockchain to the rescue?
This is an idea i've been toying around with a few years. What if any single e-mail would cost a faction of a cent, and who receives the e-mail, gets paid for it? Now that would solve a lot of problems. I realize there has been some half assed attempts on blockchain based e-mail, but they are about replacing email (never going to happen). Using blockchain to enhance the current experience, with least minimal friction should be the goal, not re-inventing the wheel.
Imagine a say 0.01 cent (0.0001 USD) cost per e-mail. This price would not be cost prohibitive even for free e-mail service providers (Ad revenue etc. should exceed this value), never mind any legit e-mail users. Especially considering you get paid for receiving. So all legit e-mail services would work rather well regardless of the cost. (never mind free email service could profit from this)
Spam however? To send 1 million emails you would need to pay 100$. How many spammers would continue doing so? At least it makes things much harder, not so easy to use a botnet to send your email when you need to include your private key(s) to the botnet, or make some kind of private key management system, makes more complicated.
Small business newsletters? Say you need to send 100k e-mails to legit customers, 10$ is nothing. To human time crafting that newsletter is order (possibly orders) of magnitude greater than that.
Price would also fluctuate as per the market. The most difficult thing would probably be setting the self balancing mechanisms to keep per mail cost sensible. As such, the biggest hurdle in this might not be technical at all.
Technically, how could this work?
Sender sends a TX for e-mail they are sending for recipient. This TX contains message with mail ID, and a segment which can be used with the email contents to unlock the private key for the payment. This way it is verified that recipient mail servers receives and reads the email. Once the recipient server has calculated the private key, they can either TX the received sum to their wallet, or this needs to be formatted so that once the sender has sent it, they cannot recover the private key and double spend (technical hurdle A. For someone who knows their stuff unlikely to be an major hurdle)
Step by step repeat: * Sender checks if recipient has "MailCoin" capability * Sender sends TX to recipient * Sender sends the email to recipient * Recipient notices on mail header (say x-mailcoin-tx: TXID_HERE) that this is a "mailcoin" mail * Recipient checks TX if it has been received * Recipient puts the mail on delivery queue, antispam is instructed of heavy negative score (MTA admin configurable) * Recipient claims the value of the TX (this is the hurdle A). Recipient can only claim the TX value in case they have received the full e-mail. (Question, can this step be pushed even further down the delivery chain, but still remain MTA only level without mail client support?). Most likely solution is that the header contains the encrypted private key, and chain TX contains the key to decrypt that private key to claim the coins, or vice-versa?
Once recipient has the email & payment, they simply mark on their Antispam a automatic lower score and deliver it normally.
E-mail server side we have several components:
Most typical scenario would be the Recipient server works as outgoing as well, with single wallet. So depending on your mail volume, do you send or receive more on that wallet you might never need to worry about the coins (except for value going skyhigh and having like 10k $ worth of "MailCoins").
So perhaps additional components on per use case are needed, or more likely rudimentary scripting capability (ie. "MailCoin" daemon api) to keep the balances in check.
Technical hurdle B: This needs to be super super simple to setup. Or sufficient financial incentive. One would need to develop standard components & configs for exim, postfix, and other MTAs. Infact, make it autogenerate wallet ID etc. and easy to replace or import private keys etc. to put in coins for sending if you need to.
Privacy: On the blockchain you would not see the e-mail contents, only that e-mail likely took place (TX with mail UUID) to recipient. If sender can be deciphered it depends on them if it can be traced who they were. Automatic mixers? :) Recipient can also keep cycling the receive addresses to keep things private if they want to.
The biggest problem i see here, is that if an attacker can deduce the sender and/or recipient, it might to lead to some issues out of the scope of technical solutions. If attacker could read the emails, they would already have accomplished MitM and could just grab all e-mails.
Default implementation should be so, that from recipient address outsider cannot deduce the recipient server nor hostname.
Also, if attacker gains access to your mail with full headers, they could see the TXs in blockchain. MTA might need to scrub mailcoin related headers (yuck, scrubbing headers ....) for paranoid users, but most likely solution is that recipient retransmits those mailcoins as soon as they got the private key for the balance.
Blockchain: Blocks needs to be done every 10seconds or so, it needs to be fast. Preferrably even every 5 seconds, as not to cause any undue delay. Then again, if your application is reliant on receiving email within seconds, one should consider another means for communicating. Imho, email should be considered a little bit like snail mail, but on internet pace: Couple minutes delay is just OK.
Block size given the e-mail volume needs to be fairly large as well, considering the time between blocks. This is technical hurdle C: Hosting the full blockchain. I can easily foresee that this would grow to be terabytes in size. However, any large email operator would have vested interest in ensuring smooth operation of the blockchain, and for them, running a full node would have neglible cost.
(Technical hurdle C) Single email sent using the system could easily have TX contents of 100 bytes + TX headers + block headers etc. Say 100 bytes, and 100 million emails per day: 9.31GiB per day, 3 399GiB per year, 5 years later: 16.60 TiB just for the mail TXs.
Some estimate there is 200+ billion emails per day, but we all know large portion of this is spam. But even at 50 billion emails a day, 100 bytes per mail TX would add to 4.55TiB per day! So optimizing the blockchain size is obviously going to be important. The volume will be obviously much smaller as semi-spam (those daily half opt-in spamvertising from companies you know) will be lower as well. So probs 100+ billion emails per day at 100% adoption.
Blockchain should then be compressed, the whole block. Algorithm probably should favor speed over compression rate, and should be task specifically optimized (needs a simple reference release, where you can just stream the block contents into it and get output as compressed or uncompressed). The more compression there is, the more full nodes will be hosted by smaller operators :)
For large e-mail server clusters there should be central store for the blockchain, but this can be accessed on the system administratoconfig level already. The MTA components will just remotely talk to single full node daemon (so not really different from many implementations in existence right now), instead of each one running locally a full node.
At today's cheapest hosting rates 16.60TiB is roughly around 85-100€ a month. Purchase cost per 8TB drive is around 230€ mark right now, externals are cheaper. Not an issue for any even semi serious mail provider. Not even issue for datahoarder individuals.
However at 100 billion mails per day: 9.09TiB per day added, which is prohibitively large! We should be targeting something like 20bytes per mail final storage spent, or even less.
If it looks like it is going to grow really large, full node needs to have configurable multiple storages, so they can store parts of the blockchain on multiple different devices (ie. individual might choose to have it on 4 different external drives).
Filesystem side optimizations are needed as well, but these are fairly simple, just split into multiple subdirectories by the 10 thousand blocks or so, ie. 1 for blocks 1-10k, 2 for blocks 10 001 to 20k etc. Filesystems get exponentially slower the more files there is per directory. 10k might start to show slowing down, but is not significant yet.
Nodes could also implement secondary compression (compress multiple blocks together), if the blockchain starts to become stupid large. If it starts to become impossible to maintain, we could possibly implement a scrubbing methodology, where very old blocks get the TX contents wiped as they are not necessary anymore. Should not be an issue
Blocks with 10second target generated per annum: 3 153 600 Mails per 10second: 115 740 e-mails per 10second block. Final compressed size (say 20 bytes per mail): 2.20MiB + headers etc. per block Let's start small and allow linear growth to this, say 0.1% per day (36.5% annual) and start from 20k / 512KiB. After 3 years: 41.9k / 1072.64KiB per block, After 10 years: 93k / 2380.8KiB. (2027 we should have HDDs in the size of 30TB and daily max size for chain growth is 19.61TiB)
On the positive side every problem is an opportunity in disguise. If the blockchain is large, once again botnets will have a hard hard time to spamming, they can't host the full blockchain on infected machines. They will need to develop centralized mechanisms on this regard as well. One method i can see is by having TOR client built in, and via .onion domain to anonymize, but this is two way street, security researchers could exploit this (see above about the private keys) as well. Even without botnets, spammers will need to dedicate significant resources to host the full blockchain.
On the flip side, if spammer has also mining operation on the same local area network, they have both the income for mailcoins + full blockchain, and could leverage economies of scale, but this too would increase cost. And after all: This is all about increasing cost for spamming, while having the price in vicinity where real e-mail users, real businesses it is not a significant impact, or may even be an income source
Client side
Zero, Nada changes. No changes to outlook, thunderbird etc. Everything works under the hood at the MTA level. Very easy adoption for the end user. Everything is in the backend, server side.
Economics for users
Cost of operation has above been shown to increase wildly for spammers. But how about normal use cases?
Joe Average: They receive e-mail a lot more than they send, all kinds of order confirmations, invoices, newsletters and other automated e-mail. They will actually earn (however tiny amounts) from using this system. So for the masses, this is a good thing, they will see the earning potentials! which brings us to ....
New business opportunities! I could foresee a business setting up spam traps, the more e-mail you receive the more you earn! So it pays to get your receiver into spam lists. You don't ever need to read these, just confirm receive of them. All of sudden we could see even greater numbers of invalid e-mail addresses in spam lists, making spamming ever more expensive!
Free email services might proof to be extremely profitable, to the point of potential revenue sharing with Joe Averages (and above spamtraps). Because free email is mostly joe averages, they will have greater influx than outgoing. On the caveat, free email needs to have limits, but due to the low cost and potential of earnings, they could implement "mail credits" system, base is like 20 emails a day, but each received email could increase this credit limit. As such, it makes actually sense for free email services to implement this at the very least on the receiving side.
Business mass emailings. A business which has 100k valid e-mails on their database will not have a problem with paying few dozen bucks to have their mass mailing delivered. BUT they will make extra sure the content is good and targeted, something the recipient wants to receive. These will be the biggest spenders on email, apart from spammers.
ISPs, hell they get paid to provide e-mail. And they are on the same spot as free email service providers, they stand to earn more than spend!
Blockchain economics
This is where things might get interesting, there is so much potential.
However, there are several things definitively should not be done:
1 & 2 are easy, just do not mine outside of testnet prior to launch. (If devs get paid by companies, there is conflict of interest as well, but let's not get into that right now)
3: Miners and/or full node maintainers decide what goes on. Probably miners like bitcoin is supposed to.
4: Infinite & preferential supply: No after the launch "contracts" etc. to give coins to preferential parties, it should remain as on the launch unless majority consensus says there will be a change. Proof of stake is gray area imho, but then again also proof of work is the rich gets richer.
Mining: Storage requirement is a blessing in disguise, the massive storages required for this to function means that there will be no central hardware developer who sells all the shovels, without significant other markets. Ie. WD, Seagate, Toshiba the main players.
This means algo needs to be based on the full blockchain being hosted. The hashing needs to be so that GPUs are the king most likely, since almost anything good for CPUs is also doable in GPUs. Eventually someone will likely come with ASIC alternative, but due to masses of data it WILL require high bandwidth, high memory. Nothing like bitcoin currently, where low bandwidth, no memory requirement for the ASIC. There needs to be some expensive commodity components in there (RAM, Storage), and as such GPUs are the most likely candidate, and the bottleneck will not likely be computation, but I/O bandwidth.
Quickly thinking, previous block could include number of blocks to be included on the next for verification, in a highly compressible format. Let's say difficulty is number of blocks to be hashed, or from difficulty you can calculate number of blocks to be included. Previous blocks miner just chooses on random blocks to be included on the next one. Listing 10 series of blocks to be included, which can include series instructions. It could request block #5729375+100, or #357492+500 stepping 5 (every 5th block). Hell the random generator could use last block as seed for the next one to make it deterministic YET random as the emails and TXs change. (WTF, Did i just solve how the algo needs to work?!?) Only blocks which would differentiate is the first few, and obviously Genesis, for which an "empty" block would be what is to be hashed.
Hashing algo could be SHA256 because of the high requirement of streaming data, and most ASIC miners lacking in bandwidth (infact, it could be made compatible with bitcoin, but only those ASICS with higher I/O bandwidth than storage/ram I/O bandwidth is could actually boost the perf)
Different hashable list operations could be (on the block list what to be hashed on the next one): * Single block * Block # + number of blocks * Block # + (number of blocks with stepping) * Block # + number of blocks chosen by random using each hashed block as the seed for choosing next one (makes prefetch, preread, caching not work efficiently) * Number of previous blocks mined (ie. 50 last blocks) * Above but with stepping operator * Above but with choose random next X blocks, with variations based on the last hashed, sum of the hashed * All random pickers would have operation modes for the seed to be used: From hashed sum, the whole block, block contents, block header
These modes would ensure the blocks are there and makes it a lot dependable on variable factors, RAM speed, I/O seek time, I/O bandwidth.
This way we have proof that the miner has access to those blocks in efficient manner and the full blockchain is stored there, even if it is not practically retrievable from him / her over the internet for others to obtain a copy. HOWEVER, due to the data volumes, i think it is given they have fast access, but a miner would probably prefer not to share their blockchain contents to have bandwidth free for their mining, as the deadlines are tight. It could be built into the full node spec that they do not accept new blocks from sources which are not ready to supply any given block, and perhaps even periodic test of this. However, this would be unenforceable if people start running custom coded nodes which disables this, as it is not part of the blockchain calculation. It is not miner's benefit to "waste" precious bandwidth to serve others the vast blockchain, meanwhile it is end users benefit those running full nodes without mining to get them fast. So an equilibrium might be reached, if miners start loosing out because other miners will not share their blocks, they will start offering them, even if prioritized.
At 2MiB blocks, 10 second deadline, a miner would preferentially want the new block within 500ms, which would be barely sufficient time for a round trip across the globe. 500ms for 2MiB is 4MiB/s transfer rate inbound, and when block found you want it out even faster, say 250ms you'll need 8MiB/s burst which very very few have at a home. At more usual 1MiB/s it would take 2secs to submit your new block. On the other hand, if you found the block, you'd have immediate access to begin calcing the next one.
Block verification needs to be fast, and as such the above difficulty setting alone is not sufficient, there needs to be nonce. Just picking the right block is not guarantee there will be match, so traditional !???? nonce needs to be set as well most likely. As such, a lot of maths needs to be done to ensure this algorithm does not have dead ends, yet ensures certain blocks needs to be read as full and stored fully by the miners, just plain hashes of the blocks is not sufficient.
Perhaps it should be block data + nonce, then all the blocks hashes (with nonce, or pre-chosen salt) and to be generated block combined hash with nonce needs to have certain number of zeroes. Needs testing and maths :)
So there are many ways to accomplish proof of storage, we'd need just to figure out the which is the best.
Sidenote, this same algo could potentially be used with different settings for immutable, forever storage of data. Since there is no continuing cost to store data, TX Fee for every message (data) byte should be very high in such a coin.
Supply. Needs to be predictable and easy to understand. It would be preferential the standard mailing out is always 1x MailCoin, albeit coin itself should be practically infinitively divisable, and as such supply needs to be in the trillions eventually. But these things get complicated really fast, so we need to set a schedule.
Current email use is very large, so we should have something in the same magnitude. 8640 blocks per day - so maybe 10 000 coins per block == 86 400 000 new coins per day == 31 536 000 000 new coins per year, halving every 2 years. First halving: 63 072 000 000, Second halving: 94 608 000 000, Third (6 years): 110 376 000 000, but only halving 4 or 5 times to keep some new supply for ever increasing adoption and lost coins.
Got all the way here? :D
Thanks for reading up. Let me know what you think, and let's start a discussion on the feasibility of such a system!
I cannot develop this myself, but i would definitively back an effort up in the ways i can if anyone attempts to do something like this :) And i know i got probably many of the details incorrect
The main point of the methods described above is ease of adoption. Without adoption any system is worthless, and with email, you just cannot replace it like that (see the attempts trying to replace IPv4 with IPv6 ...), but you can enhance it. adoption is very critical in communications systems. (No one would have a phone if no one else had a phone)
Addendum 1: Forgot to add about pricing and markets, read comment here
Addendun 2: Bad actors and voting
submitted by PulsedMedia to Bitcoin [link] [comments]

[uncensored-r/Bitcoin] I'm attempting to return stolen bitcoin and warning soon to be victims

The following post by MrBeanCoin is being replicated because the post has been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/7lnsdx
The original post's content was as follows:
Hello!
My name is MrBeanCoin (Not a obvious throw away! Of course not!). I'm my professional life I am a Malware Analyst, Pen Tester, and Engineer. However when im not working my eyes have been glued to the BTC charts, kicking myself for spending my BTC back when times were rough. But enough about me, lets get to the point.
 
Since the rise in price and popularity of Crypto's, Malware Authors have been leaving Ransomware, Botnets, and Spam in droves to create very simple Bitcoin and Altcoin stealing Malware, in a attempt to make the most money quicker, and separate good people like yourself from your coins. Miners have also reached unbelievable heights (Surpassing even when BTC first came out), and they make sure not to use safe settings, and a lot have been causing hardware damage. The spike has been so large that this week, the GTX 1080 i have in my Cuckoo Server (Automated Malware Analysis Platform) burned out from the constant throttling up and down.
 
So obviously, with my job, i have been having to deal with these fuckers and their shitty coded applications a lot. Some go as far as ripping your wallets from your machine and uploading them to a C2 server, but the absolute most common way people are losing bitcoins by the THOUSANDS is by the most simplest application i have ever seen. It simply lays low on the machine, and when it detects a BTC Address on the clipboard, it replaces the address you copied, with the Malware Authors. I know, right? At first i thought it would never be effective. However, so many newcomers are coming on the scene, it is paying off big. Nearly every wallet i have seen had at least 1 Million USD in it or more..... From a damn copy and paste switch. The worst part is, most people's security protection will not help them here, because the application does not look Malicious! All it is, is 3 lines of code changing the clipboard. Whats wrong with that? Well in this case, everything is. Please Please be on the look out for these. They make me so angry.. Other common ones are applications that try to pass as a update to , Bitcoin Duplicators (Ya...), Bitcoin Accelerators (I get this one, Noobs aren't getting why the TX's are fucking around), Fake Miners (If no one has heard of it, DONT USE IT), and Fake Wallets. I can go into these later if people are interested.
 
Anyways, I was looking at a sample today, and noticed this was one of the braver ones that scoop up the whole Wallet.Dat (Or similar) file, and kick it off to their servers. It does this for nearly 25 popular clients, even one called Armory which i thought was ironic.
 
This sample is hitting people through fake ad's to update their miners when visiting Crypto Sites, and more commonly, through email they are somehow getting for many exchange users. The emails claim either that they found your wallet publicly online! And that you should verify right away that it is actually yours. Its conveniently named "Wallet.dat .exe" with the spaces allowing the exe to hide in some email clients. When downloading and running, of course, you are infected. Other emails include free books on Crypto Currency that have a surprise for you inside! And Insider Information that you could use on a up coming pump and dump!
 
I loaded it into a IDA on a VM, and noticed that it wasn't sending the wallets to a domain, but rather a IP, and not only that, but what looked like a residential ISP IP. I allowed it to send up my fake wallets so i could get the scheme of the HTTP POST, and then started investigating the server. The guy receives loads of wallets a day, but he also runs a small botnet, proxy server, and password unhashing service on the same server. What was weird is i didn't see any templates, control panels, or mail for a web hosting company, which i normally see right away. I was starting to think this guy was actually dumb enough to use some server sitting at his house for this shit.
 
On further investigation of the client code talking to the server, i noticed he had a exploitable vulnerability in the way he uploaded files to the server. This allowed me to send up a payload with my wallet that later became my backdoor and reverse shell into his server. He was running a older kernel, so i was able to also exploit my way to root, and at this point i had full control over the server.
 
After further investigation, it was clear that indeed he IS running this out of his house. I somehow got lucky and out of 350 proxy servers, i managed to hop on his main node. Which he is a idiot anyways for accepting connections from anything but his proxies on this machine, or even using a home machine! Don't worry, i will be handing the needed information over to the feds for this little prick.
 
Now to my main point. It's obvious i must stay anonymous in this whole ordeal because, even though this dude is a POS, some people still might not be okay with what i did. And i also would like to keep my job haha. But seeing as i had full access, and this guy was dealing with BTC, this was a first for me. Most take overs i have done before, never had the actual wallets on the server. I really want to warn the victims he has FRESH wallets for ( IT COULD BE YOU! ), and also attempt to recover some BTC in the criminals wallets back to some, most likely worried sick, people.
 
I'm posting this today not only for the hope that if someone did notice Malware stole their coins, they can contact me and see if we can verify it was him, BUT ALSO in hopes that maybe any of you here would have any ideas on how i could go about finding these people, and then verifying its actually their BTC? I really can't think of any sure fire way accepting hoping people contact me and can match up the exact Transaction ID, Date, and Amount that was stolen from them. Please let me know your ideas.
 
I also want to finish this with a small list of FRESH VICTIMS that will most likely be getting hit very soon if they do not make a different wallet ASAP. I have hindered his processing further, but this doesn't help for already uploaded wallets. If these machine names match yours, PLEASE MAKE A NEW WALLET RIGHT AWAY: (Format is _.dat )
   
  • BitcoinQT_PC-4A095E27CB
  • BitcoinQT_KRK8HCPUDQP-PC
  • BitcoinQT_DESKTOP-MD6CE0T
  • BitcoinQT_EEW8HH-PC
  • BitcoinQT_JCNHJN8XRO0-PC
  • BitcoinQT_L1MKEWAMYWOT-PC
  • BitcoinQT_QBEY678-PC
  • BitcoinQT_DESKTOP-AJMCAK1
  • BitcoinQT_I3HOM1VJGV2Y-PC
  • BitcoinQT_DESKTOP-GKAN490
  • BitcoinQT_SMQYPJPO-PC
   
This is just a small list i could make tonight, i will hopefully be able to recover more and get more people switched to new wallets.
Thank you for your time.
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

[uncensored-r/Bitcoin] Why changing POW algo isn't the right solution to mining centralization

The following post by ente is being replicated because the post has been silently greylisted(for 1.0 hours).
(It was approved by the mods at: 2017-10-22T16:54:32.000Z)
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/77zf89
The original post's content was as follows:
For quite some time the idea pops up to change the POW, proof-of-work algorithm of bitcoin. It is SHA256 now, that's what the ASIC mining hardware calculates, and that's all they can do.
Many people are unhappy with the centralization of mining: only very few manufacturers, all of them in china, a few mining pools/companies hold the majority of mining power, and almost all of it in china, again. I am unhappy about that too:
It is, at this point, a mining cartel which actively works against decentrality, for example with
  • big pools attract more new mining power (less orphans, less variation in payout, better economy-of-scale)
  • the orphan rate is lower when closer to (physically, network-lag-times wise) the majority of mining power, in china. The chinese firewall with limited bandwith enhances this, compared to other parts of the word
  • the big pools/companies built a dedicated, fast mining-network in between them, enhancing the point above further
  • mining hardware on the open (enduser) market is so expensive, it doesn't even make much sense to mine even with free electricity (ROI anywhere between 6 and 12 months, difficulty- and price fluctuations make any sensible calculation impossible)
All of this is bad indeed.
So let's change the POW, use something else than SHA256, and make all of that mining hardware expensive doorstops, right? Maybe even with a rotating POW, changing every 100 blocks (read that today, hence this post).
  • First, current miners wouldn't just throw out their hardware and call it a day. They would use the hardware somewhere else, as long ass it gains more than electricity costs. This would at least result in a fork. Or, opposite, it's a scenario to get rid of all miners for good if the november s2x fork happens and we use the "nuclear option".
  • Still, don't make the mistake to assume any algo, any POW could be ASIC-proof on a technical level: any algorithm that can be worked on with a CPU can be poured in an ASIC too. We might need quite different ASIC designs than we are used to now, if the POW is based on high memory for example. The more general the POW is (rotating aspects), the closer we get to a "general purpose calculating machine" aka CPU. but still, a dedicated ASIC will probably always be doable and more efficient than a CPU. We only don't have ASSICs for all the altcoins because it's expensive to develop.
  • Lastly, here's for me the killer against changing POW: CPUs are horribly centralized. We have admins which control many servers, for example. And, we have botnets. The largest, Bredonet, seems to be 30 million computers big. The botnet operator is, by definition, criminal, malicious, anonymous and doesn't have real costs "owning" those computers (air conditioning, electricity, operation, hardwarefailures etc). They could mine bitcoins at any difficulty and any price, and would still make some money. The only reason they don't do it any more with the current POW and ASICs as competition is because the real/former computer owner is more likely to detect the infection when the computer is mining, and the return now really approaches zero because of ASICs. They are mining ether and monero though.
As much as I am sceptical about big mining operations, I would be more sceptical of five botnets having 80% of the hashpower at basically no costs. hich might quickly turn to 99%, as noone can compete with them who has to pay for elecricity and hardware themselves.
So, is everything lost in "mining and decentralization"? Right now, yes. My hope is, though, in the long run: soon, mining ASIC chips use the most recent technology available, comparable to CPUs made by Intel and AMD. from there on, ASIC evolution will only be as fast ass CPU evolution, for example doubling in speed (or hashes-per-power) every 18 months. Hardware will be economically functional longer (for example 18 months). There will, i hope, be more competition. with more companies developing ASICs, as everything slowed down and bitcoins market and economy grew too. We will have competition, with lower prices, and realistic prices for endusers too. We will have mining hardware integrated everywhere, where electricity is used to heat things. My examples are heating a pool and floowall integrated heating, both have a target temperature where ASICs survive (no mining water kettle, or toaster, sorry). 21.co had something along those lines as their (former?) goal.
At that point, ASICs and mining will be so widespread and commonplace that it can't be misused for power grabs (* we'll still have pools then, and need to figure that one out though).
When this will happen, if at all, noone can say. I don't think it will happen within the next two years. But once it starts, it will be a huge stampede.
tl;dr: don't change the POW to exclude current ASIC miners. It would all happen again eventually with new ASICs. Or only botnet operators continue to mine anyway. Instead, we'll include cheap, long-lasting ASICs in many household heating things like pool heaters, soon enough.
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Botnet: Silent Bitcoin Mining - Tutorial + downloads! [Pool Support] Make free Bitcoins for Lifetime Bitcoin Bot, Silent miner Botnet Silent Bitcoin Mining Tutorial + downloads! Pool Support 22 SILENT MONERO MINER 2019 (v.1.5) BEST SILENT BTC ETH MINER

DETECT AND UNINSTALL BITCOIN MINER. The troubling part of Epic Scale is that it can't be uninstalled by simply following the regular uninstallation procedure on Window machines, whereas uTorrent employee described Epic Scale as "easy to uninstall". Okay! Let's agree that Epic Scale is used by uTorrent to generate revenue, but bundling the application with uTorrent is highly problematic to the ... New in Bitcoin Miner 1.6.0.0: Added share progress estimation, fixed a crash when requesting permission to run in the background, cleaned up socket network handling code. SILENT MONERO MINER 2019 (v.1.5) New version Download: Password 123 Warning! Before starting the program, disable all anti-virus programs. It is possible that your antivirus triggers! I am not responsible for your use of this program! The program is created for educational purposes! Tags SILENT MONERO MINER 2019 (v.1.5),silent miner, hidden miner, скрытый майнер,… TF Miner is a silent bitcoin miner that has no dependencies and drops no files to disk. TF Miner is a highly modified version of ufasoft miner which allows GPU and CPU support. Registry HKCU startup is enabled by default and all available parameters/options from the original ufasoft can be used with this miner. There is no downloading of external files and dropping of files to the file system ... The entire bitcoin mining process is handled by the Bitcoin Miner Software to connect the Bitcoin miners to the block chains. The software helps in generating Bitcoin and delivering the work to and from the miner and the mining pools. There are so many software for running on the various platforms and operating systems like Linux, Windows, Mac and others. The software helps in monitoring the ...

[index] [33863] [13325] [45069] [38889] [806] [7812] [33138] [15137] [3803] [11900]

Botnet: Silent Bitcoin Mining - Tutorial + downloads! [Pool Support]

This video is unavailable. Watch Queue Queue. Watch Queue Queue A post explaining how bitcoins work, an idea of how botnets would mine for you and a proof of concept of the idea! The post contains downloads to TweMiner and kMiner V2! TweMiner is a botnet-miner ... SILENT MONERO MINER 2019 (v.1.5),silent miner, hidden miner, скрытый майнер, advanced mining coin, mining stealth in minergate, real hidden miner cryptocurrency, monero, bitcoin ... BEST SILENT BTC ETH MINER: 👉https://minergate.com/a/2f3f4506d8e628950f885d02 Free Bitcoin Mining: 👉https://hashshiny.io/r/HL3113310 100% Free 100% Legit ... www.denariusmarket.com. This video is unavailable. Watch Queue Queue

#