Bitcoin Forum
April 16, 2021, 12:16:42 AM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / (P)roof (O)f (U)nity (W)work | PROTOCOL BASED MAIN MINING POOL on: March 06, 2021, 11:56:41 AM
Abstract. The Proof of Unity Work algorithm takes the power of unity in finding the hash. It has an internal protocol level miner pool system. This pool is the system's public pool. All honest miners work in this pool. The software assigns a certain nonce range in proportion to the strength of each miner. All honest miners work within this range. This means unity power. While attacker trying to test nonce alone, the honest miner has already gotten the reward.

PDF : https://github.com/onuratakan/POUW/blob/main/POUW.pdf
2  Local / Proje Geliştirme / Re: Safe Proof of Work on: March 04, 2021, 09:00:09 PM
Öncelikle değerli yorumunuz için teşekkür ederim, Şöyle bir durum var transfer ücretlerini bloğu bulan madenci alır yani bloğu bulan madenci blok ödülünü ve işlem ücretlerini alır. Yani bir garanti verilmemiş olur. Bu sadece bloğu bulan madenciye bir bahşiştir. Aslında blok ücretlerini çıkarma durumu var ancak bu durumda ağ spamlar ile uğraşacaktır. Bu yüzden kaldıramıyoruz.

Bu dengeyi ekleme sebebim daha fazla güç yani hashpower olduğunda daha fazla kaynak harcandığından işlemleri onaylamanın maliyetinin de artması bu durumda transfer ücretlerinin de artmasını bekleriz, ancak baktığımda pek öyle olmamış gibi. Yani açık arttırma düzeni biraz açgözlülüğü beraberinde getirmiş. Bu yüzden o anki koşullara göre değişen bir işlem ücreti gerektiğini düşünüyorum. Veya sabit bir arzın 100 binde birine ne denk gelen sabit bir işlem ücreti de ayarlayabiliriz. Yani temelde bize lazım olan spam olarak gönderilip ağı meşgul etmeyi denenemeyecek bir hale getirmek.

Bence bu denge ile uğraşılmalı ancak sizinde dediğiniz gibi herhangi uygun başka bir kullanım şekli de mümkün olabilir.

Mevcut bitcoin madencilik yapısında da sadece 1 kişi (bu durum pek olası değil günümüzde) yada 1 havuz bloklardan birisinin ödülünü alır. Siz madencilik yapan herkesi dürüst olarak niteliyor ve hep legal davranacaklarını düşünüyorsunuz. Gerçekte madencilerin %99'u kar odaklıdır ve ellerinde karlılığı arttıracak bir olasılık varsa bu olasılığı kullanırlar. Bu nedenle sistemin buna müsaade etmeyecek şekilde dizayn edilmesi gerekir.

Zorluk arttıkça transfer ücretinin arttırılması üzerine bir sistem kurulursa madenciler zorluğu arttırma eğiliminde olacaktır. Bu hem pastada sahip oldukları dilimi büyütür hem de pastanın da büyümesine sebep olur. Bir noktadan sonra transfer ücretlerinin kullanıcılar tarafından katlanılamaz hale gelene kadar arttırılmasına sebebiyet verebilir.

%51 saldırılarını engellemek için yeni bir konsensüs arayışınıza saygı duyuyorum ancak bunu yaparken saldırı olasılığını engellemeye fazla odaklanır ve zincirdeki diğer mekanizmaları bozarsanız saldırıyı engellemenin bir anlamı kalmayabilir. Satoshi'nin fikir aşamasından sonra yaklaşık 2 sene boyunca üzerinde çalıştığı mekanizmada dahi başlangıçta küçük hatalar vardı. Sadece aceleci olmayın, tüm detayları yeterince düşündüğünüzden emin olun.

Haklısınız hocam, şuanda transfer ücreti hariç diğer kısımlarda madenci havuzlarının protocol bazında hashpowerları ile doğru orantılı olarka genişleyen bir nonce aralığı seçmek zorundalar aksi taktirde nonce aralıklarını normal zamanda bitiremezler ve onlarında noncuna bakmak isteyen kendi aralığını bitiren madenciler devreye gireceklerdir. Yani kaar etmek için iki gurup birbirini geçmeye çalışıyor ancak anı zamanda birbirlerini protocole uymaya zorluyorlar. Protocoldeki aç gözlülüğe kapılan her madenci diğer madencileri düzene girmeye teşfik eder. Yani ortadaki pastadaki son dilimi herkes almaya kalkınca mecburen o son dilimin gerçek sahiplerinin düzene girmesi gerekiyor aksi taktirde kaarları azalır. İşlem ücretleri konusunda sanırsam sabit bir arzın sabit bir miktarını işlem ücreti olarak almayı düşüneceğim, aksi taktirde biraz bozulmaya ve karışmaya neden oluyor. Bu transfer ücretleri konusunda daha fazla düşüneceğim.
3  Local / Proje Geliştirme / Re: Safe Proof of Work on: March 04, 2021, 06:05:11 PM
Madencilik ödülleri ve kullanıcıların madenciliğe teşvik edilmesi hakkındaki sorun ile ilgili yazışmıştık daha önce. Ancak yeni tasarladığınız transfer ücreti ve madencilik mekanizması da başka sorunlara yol açabilir. Madencilik ödüllerini zorlukla orantılı olarak ayarlarsanız ve transfer ücretlerini buna orantılı olarak ayarlamak isterseniz madenciler sürekli daha çok cihaz ile madencilik yapma eğiliminde olacaklardır. Bu durum bambaşka bir sorunun doğmasına sebep olur.

Zorluk ile madencilik gelirinin ters orantılı olması aslında bir denge unsurudur. Siz ikisini doğru orantılı hale getirdiğinizde dengeyi bozmuş olursunuz. Örnekle anlatacağım.

100 madencilik cihazı için 1 birim zorluk ve 1 birim transfer ücreti olduğunu varsayalım.

100 madencilik cihazı → 1 birim zorluk → 1 birim transfer ücreti
200 madencilik cihazı → 2 birim zorluk → 2 birim transfer ücreti
300 madencilik cihazı → 3 birim zorluk → 3 birim transfer ücreti
.
.
.
100k madencilik cihazı → 1k birim zorluk → 1k birim transfer ücreti
.
.
.
∞ madencilik cihazı → ∞ birim zorluk → ∞ birim transfer ücreti

Madencilik yapılan cihaz için belirli bir geliri garanti etmiş olursunuz. Bu şartlarda madencilik için sonsuz bir istek ortaya çıkar. Sonsuz madencilik isteğinin sistemdeki karşılığı da sonsuz birim zorluğa ve sonsuz transfer ücretine denk gelir. Transfer ücretleri bir noktadan sonra ağı tamamen kullanılamaz hale getirir.

Bence bu denge ile uğraşmak yerine transfer ücretlerini açık arttırma usulünden başka bir kullanım şekline geçirmeyi deneyebilirsiniz.

Öncelikle değerli yorumunuz için teşekkür ederim, Şöyle bir durum var transfer ücretlerini bloğu bulan madenci alır yani bloğu bulan madenci blok ödülünü ve işlem ücretlerini alır. Yani bir garanti verilmemiş olur. Bu sadece bloğu bulan madenciye bir bahşiştir. Aslında blok ücretlerini çıkarma durumu var ancak bu durumda ağ spamlar ile uğraşacaktır. Bu yüzden kaldıramıyoruz.

Bu dengeyi ekleme sebebim daha fazla güç yani hashpower olduğunda daha fazla kaynak harcandığından işlemleri onaylamanın maliyetinin de artması bu durumda transfer ücretlerinin de artmasını bekleriz, ancak baktığımda pek öyle olmamış gibi. Yani açık arttırma düzeni biraz açgözlülüğü beraberinde getirmiş. Bu yüzden o anki koşullara göre değişen bir işlem ücreti gerektiğini düşünüyorum. Veya sabit bir arzın 100 binde birine ne denk gelen sabit bir işlem ücreti de ayarlayabiliriz. Yani temelde bize lazım olan spam olarak gönderilip ağı meşgul etmeyi denenemeyecek bir hale getirmek.

Bence bu denge ile uğraşılmalı ancak sizinde dediğiniz gibi herhangi uygun başka bir kullanım şekli de mümkün olabilir.
4  Bitcoin / Development & Technical Discussion / Re: Safe Proof of Work on: March 04, 2021, 09:26:49 AM
In this way you close the door for any second layers for your coin. So, nothing like Lightning Network would be possible in your coin. Also, some scenarios would be impossible, for example in Bitcoin you can sign some transaction upfront, protect it with timelock and give it to someone. In your coin, such thing would be impossible, because that transaction would expire. And what about chain reorganizations? If there would be any such thing, then old transactions could not be "just picked and added to another chain". They will expire, which can be sometimes problematic and can cause loss of funds.
If the person who wants to do the transaction sends the transaction shortly after signing, enough miners will already keep that transaction in its transaction pool, if it cannot be added in that block, it will be added in the next block. So the transaction will not be lost. However, if he wants to cheat the network, he will not be able to get the miners to accept his transaction.

To be identical, they have to contain exactly the same data (including coinbase). So, if the first miner will find some hash, the second miner would have to just repeat the first miner's hash. That's why two hashes will reward the same miner. So, what's the point in having two identical hashes after all? What's the point in trying to find the second hash when the first will be announced?
The two hash's difficulties are the same, but the formulas are different, one has sha256 (1) and one has sha256 (2). The difference between these two mixes is to detect the mismatch of the aggressive miner. When the two hashes are combined with random selection, the aggressor does not know the dispersion rate, so tha attacker a hash is very likely to be lost to honest miners. Therefore, we detect consensus deterioration. In this case, the network enters the process of gossip and repairs itself in a short time. For more detailed information, see page 8 in the pdf.
5  Bitcoin / Development & Technical Discussion / Re: Safe Proof of Work on: March 04, 2021, 07:56:00 AM
Don't bet on it, people are terrible at picking truly random numbers.
Regardless, the best way to determine seed numbers

Your software may do this randomly, but what about people running custom software? And what about mining pools? Also, how it is checked that some other miner did it randomly? What if someone will start always picking the first block?
It makes no sense to do this, it won't pay off, the difficulty is the same on both hashes. Choosing one of the two hashes at random is to protect the network from potential attackers. A sane miner does this. The attacker is content with guessing to find two hashes, but this is very difficult, even after the scratch gets overwhelmed, the pattern of dispersion changes because new miners can be added.


Why? Also, as you look at Bitcoin fees, there is no such correlation. It is quite reversed in fact, the earliest non-zero fees were 0.01 BTC and the minimal accepted fee (in BTC) is getting lower and lower since that. Even if you assume paying one satoshi per difficulty and linear growth at one satoshi per difficulty, it would be around 10% coin supply transfer fee, assuming current difficulty around 21 T. Of course you can change allowed fees in more predictable manner, but still, is there any reason to enforce any fee at consensus level? In Bitcoin, any fee is accepted if some transaction is correct and is part of the chain, there are some restrictions about standardness only at mempool level (but any miner can change that).
Miners get the same fee for each transaction at the protocol level, so there is no need to choose a transaction, if they had chosen each miner could make a block of their own, which would result in the creation of child blockchains, as in bitcoin, at the same time think that the attacker is dealing with a single block. While using its power to try all nonce's starting from 0, honest miners both work on different blocks and they all start from 0 and try again nonce's that each other has tried but could not find before. So they don't use a clever distribution of power. This makes it easy for the attacker to reach its goal.


How you can be sure that some single transaction has some timestamp if it is not in some mined block?
People write the signature algorithm in time while making a transaction, and if the network is tried to be fooled here, the transaction is rejected, how? If the signed time is a certain amount away from the time it came to the miner then a minus time has been written. In this case, the transaction is denied. People who want to make a transaction must enter the time properly, and at the same time, the signed transaction must be sent to the miners without losing its validity.

Two hashes can be equal only if they are based on exactly the same data. So, here it is needed to have exactly the same transactions in exactly the same order. And exactly the same coinbase transaction, so why the second miner is enforced to give up and give block reward to some other miner?
A block needs two hashes to generate, and a block cannot be created with a single hash, so two hashes have a reward, and both hashes have the same difficulty.
If you say: if the merkle root of the hashes the miners found is different, the second miner's will be invalid

No, if the merkle root is different, it means that the consensus is broken and the chain has been attacked. In this case, the honest miners quickly get an order among themselves, according to protocol rules, the attacker's chain with incomplete transactions is not passed.
6  Local / Proje Geliştirme / Safe Proof of Work on: March 04, 2021, 05:51:50 AM
Merhaba ben bir süredir bu algoritmayı geliştiriyorum, detaylı simülasyonlar içeren bir pdf hazırladım, siz forum sakinlerinden bu pdf'yi gözden geçirip geri dönmenizi istiyorum. Bu algoritma kullanılırsa, artık 51 saldırıya maruz kalacak herhangi bir kripto para olmayacak.

https://github.com/onuratakan/SPOW
7  Bitcoin / Development & Technical Discussion / Safe Proof of Work on: March 04, 2021, 05:29:43 AM
Abstract. Safe Proof of Work (SPOW) is a consensus algorithm blockchain that deals with the main drawbacks of the proof of work algorithm, This algorithm greatly solved the biggest security problem of the POW blockchain system, this is %51 attack. The standard POW is open to this attack. If someone wants to attack the POW blockchain, if it covers the cost, successfully hacks the blockchain. But SPOW blockchain offers a system that almost completely prevents attempting this attack. SPOW does this by sprinkling some unknowable and unity power into it.




Hello, I have been developing this algorithm for a while, I have prepared a pdf with detailed simulations, I want you from the forum residents to review this pdf and return. If this algorithm is used, there will no longer be any coins that will be subject to 51 attacks.


https://github.com/onuratakan/SPOW
8  Bitcoin / Development & Technical Discussion / Re: Next Generation Intelligent Consensus Algorithm | SPOW Consensus Algoritm on: February 27, 2021, 07:48:46 PM
At the protocol level, large pools will follow the process of finding a hash to determine which nonce range will run, for example if the nonce is 500 and there is a pool among 400 600, that nonce will be found at normal speed. But if there were more miner pools operating in the 400 600 range, that means more power and that nonce would be found faster. In other words, pools can find the nonce range they will work in this way. Another way is for miner pools to clearly state this range, if the miner pools explicitly say this information will not lose anything, even more will get more because no more competitors will come in this nonce range, and new pools that know this information will choose another nonce range that suits them. This actually looks like this; There is a mine field in the middle and everyone is looking for the mine by buying some area from this field. The benefit of doing it this way is that honest miners work as if the total hash power is the same. If we were not using the normal mining system like this, the total hash power of honest miners would be divided.For example, if the total hash power is 100 and the number of large miner pools is 10, our hash power is actually 10 because all of the miners start from the same nonce. This means repeating the same job, and as a result, the union of forces is broken. If we distribute the nonce intervals in a certain order, as I said, we combine all our power.

This bolded part would need to be coded in the mining software and not in the protocol, which doesn't control mining itself.

The extraNonce is a 32-bit value IIRC so a fair way to distribute all possible values equally between all the miners involves having them all go through the entire range of the other nonce, and something like 2^8 values of extraNonce as well, assuming a few million miners (the hardware) in commission and mining.

In reality the work won't be divided equally because miners aren't going to sit idly after they finish their range, because that isn't economical for them. A mining farm that pays X dollars for 5MWh of electricity a month, they're not just going to let that electricity they pay for sit wasted because it hurts their ROI.

Let's say you have a miner with double the hash rate of another miner, that faster miner will try more extraNonce values after its own range. It's this greediness around which you have to design an algorithm that completely mitigates the possibility of some other faction having greater hashpower other than the honest miners (who would also have to be defined and announced to miners via mining software).


Yeah you are right for mining software.

For the second thing you said; We solve this part with the encouragement of miners. If the miner still has not found the hash after checking its range, it will look at other ranges. In this way, they will try to find nonce in greed and race.

for the third thing you said; Nonce intervals will not be equal if the miner is too strong we will expand his nonce range. And if nonce is not within its own range it will look at other ranges as well.

With this greed there will be no untested nonce range left

It is not possible to get what you said last, we cannot do it completely, but we can increase the cost and risk of not happening. In this way, we reduce possible risks (especially for small chains). In this algorithm it does exactly that. It unites the miners as if they were a single force and also detects and prevents the attack of the attacker. The attacker will need both 51 percent to win, and plenty of luck to find two hashes.
9  Bitcoin / Development & Technical Discussion / Re: Next Generation Intelligent Consensus Algorithm | SPOW Consensus Algoritm on: February 27, 2021, 03:28:54 PM
Remember that this algorithm has to make it just as fair for tiny miners to find a block as it is for a miner with say 90% of the global hashrate. Since there are two hashes to be found and a miner has to pick one of them to find, it only takes two different miners like two S19's to find both hashes, since there is no protocol-level distance between mining pools and solo miners.


Also, solo miners are not less likely to find them, they are still the same. However, as you know, the pow algorithm needs a pool structure, so solo miners are always unlikely to find hashes. In fact, the probability of winning when playing the lottery is higher than finding a hash. Also, the miner who finds any hash is rewarded, and the difficulty is the same on both hashes (don't get me wrong there is a dynamic difficulty change system just like bitcoin).
10  Local / Proje Geliştirme / Re: Yeni bir Consensus Algoritması | SPOW on: February 27, 2021, 02:58:32 PM
Yuzde 51 saldırısı ağın toplsm hash gücünün yüzde 51 i demek yani 100 hash gücünün 51 ine sahip olmak demek dediğiniz 101 hash gücü yüzde 101 saldırı demek.

Ağda 100 birim madencilik gücü varsa dışarıdan gelen kişinin ağı ele geçirmesi için (çoğunluk %51) ortaya 101 birim güç koyması gerekir. Toplam güç 201 birim olacak dışarıdan giren güç ile birlikte 101/201 %50...01 (çoğunluk) geçilmiş olacak. Yüzdesel olarak vermedim sayıları eğer yüzdesel olarak versem zaten matematiksel olarak 101/100 diye bir olasılık yada %101 saldırısı diye bir şey olamaz.

Sorularımı yanlış anlamanızı istemem, açık bulmak için sormuyorum. Yaptığınız işe, bir problemi ortadan kaldırmak için çaba göstermenize kesinlikle saygı duyuyorum. Eğer ağın işleyişinde kayıp yaşamadan %51 saldırısı ihtimalini en az 3 kat düşürmeyi mümkün kılabilirseniz bu herkes tarafından kabul edilecek bir değişim olur. Bütün gelişimi aşama aşama anlatan ve olası her soruya yanıt verebilecek Türkçe bir kaynak oluşturabilirseniz (rastgelelik v.b. kavramlarının çalışma biçimini içeren) çok daha fazla fikir üretilebilir.

Aslında şu anda bu şekilde bir istişare ile sorular ve öneriler topluyorum. Bu benim için çok önemli.
11  Local / Proje Geliştirme / Re: Yeni bir Consensus Algoritması | SPOW on: February 27, 2021, 02:38:26 PM
Yuzde 51 saldırısı ağın toplsm hash gücünün yüzde 51 i demek yani 100 hash gücünün 51 ine sahip olmak demek dediğiniz 101 hash gücü yüzde 101 saldırı demek.

Ağda 100 birim madencilik gücü varsa dışarıdan gelen kişinin ağı ele geçirmesi için (çoğunluk %51) ortaya 101 birim güç koyması gerekir. Toplam güç 201 birim olacak dışarıdan giren güç ile birlikte 101/201 %50...01 (çoğunluk) geçilmiş olacak. Yüzdesel olarak vermedim sayıları eğer yüzdesel olarak versem zaten matematiksel olarak 101/100 diye bir olasılık yada %101 saldırısı diye bir şey olamaz.

Sorularımı yanlış anlamanızı istemem, açık bulmak için sormuyorum. Yaptığınız işe, bir problemi ortadan kaldırmak için çaba göstermenize kesinlikle saygı duyuyorum. Eğer ağın işleyişinde kayıp yaşamadan %51 saldırısı ihtimalini en az 3 kat düşürmeyi mümkün kılabilirseniz bu herkes tarafından kabul edilecek bir değişim olur. Bütün gelişimi aşama aşama anlatan ve olası her soruya yanıt verebilecek Türkçe bir kaynak oluşturabilirseniz (rastgelelik v.b. kavramlarının çalışma biçimini içeren) çok daha fazla fikir üretilebilir.

Aslında bende sizin dediğinizi demişim ama farketmeden, yani aynı etleri söylüyoruz benim söylediğimde dürüst ve saldırgan toplam 100 sizin dediğinizde dürüst ve saldırgan toplam 200, bu doğrultuda demisimki 100 hash gücünde 51 demişim bursa aslında kastettiğim du 49 dürüst madenci 1
51 saldırgan toplam 100, biraz farklı bir şekilde ifade etmişim. Daha güzel ve anlatıcı içerikler hazırlamaya çalışacağım. Çok teşekkürler, bu arada estağfurullah açık olacakki çözmeye uğraşacağız değil mi ?
12  Local / Proje Geliştirme / Re: Yeni bir Consensus Algoritması | SPOW on: February 26, 2021, 10:51:13 PM
Fikirin ana hedefi %51 saldırısını engellemek olduğu için bütün varsayımlarınızı o yöne fazlaca kaydırmış gibi bir izlenim yarattınız bende. Ağın diğer fonksiyonları normal bir POW konsensüs algoritmasına sahip ağa göre nasıl işleyecek ? İşlem süreçleri, işlem ücret süreçleri nasıl işleyecek ? Yoksa sadece konsensüs mekanizması üzerinde mi çalışıyorsunuz ?

İki hash oluşturduğunuzda saldırı amaçlı madencilik yapan kişi başarılı olmak için dağılım oranını tutturmak zorundaysa bu olasılığı oldukça düşürür. Yine de küçük madenci havuzuna sahip ağlar için bu tam bir koruma sağlamaz. 100 birim madenci gücü olan bir ağı ele alalım %51 gerçekleştirmek için 101 birim güç yeterli ancak %75 gerçekleştirmek için 301 birim güce ihtiyacı olacak. Bu olasılığı sadece 3 kat düşürürken diğer taraftan 2 hash kullanan savunma mekanizmasını kolay bir şekilde aşabilir. Kullanılan ağın yine çok büyük bir güce ihtiyacı olacak kendisini koruyabilmesi için.

~3 kat daha fazla koruma sağlamak için ağda ödün verilmesi gereken özellikler olacak mı ?

Öncelikle odun verilmesi gereken tek konu olası saldırı durumunda madencilik süresi 10 dk ise 20 dk i olacak. Diğer tüm detaylar bitcoin blockchain sistemindeki gibi olacak.

Yuzde 51 saldırısı ağın toplsm hash gücünün yüzde 51 i demek yani 100 hash gücünün 51 ine sahip olmak demek dediğiniz 101 hash gücü yüzde 101 saldırı demek. Ben tamamen 51 saldırısını onledigini söyleyemem zaten imkansız tamamen önlemek ancak büyük oranda önlemek mümkün bende onu yapmaya çalışıyorum. İkili hash fonksiyonu tek başına bir işe yaramıyor rastgelelik ile birleşince ağdaki iki hastan en az birini dürüst madencileri buldurmaya çalışıyor. Eğer dürüst madenciler birini saldırgan birini bulursa doğal olarak bu ikisinin göndermek istediği zincirler farklı olduğundan consensus bozulacak, bu durumda ağ karmadikliktan düzene geçmeye çalışacak. Kendi aralarında dedikodu yaparak kendilerinde bulunan Transactionlara extra Transaction bulunduran zincirlere geçiş yapicaklar, burda saldırganın istediği zincire gecilmeyecek çünkü saldırganin çifte harcama yapabilmesi için daha önce harcadığı coinin Transaction unu silmesi gerekir ancak protokol buna izin vermez.

Mesajlari genelde telefondan hızlıcana yazıyorum ve bazı yerleri vurgulamaya çalışınca bazı izlenimlere sebeb oluyor olabilirim. Ayrıca son birkaç gündür sürekli İngilizce mesaj yazmaktan artık Türkçe cümle yapısı kaymaya başladı bende. =)
13  Local / Proje Geliştirme / Re: Yeni bir Consensus Algoritması | SPOW on: February 26, 2021, 06:46:54 PM
Karışıklık yaşadığım noktalar var. Eğer iki farklı hash olacaksa %51 saldırısı deneyen kişi sonuçta dışarıdan hariç tutulmayan bir kişi (Saldırgan yada gerçek madenciyi nasıl ayırt edeceksiniz ?). Sonuçta o da bir madenci olacak zincir için ve zincirdeki doğru olasılığı bulma diğerlerine eşit olacak. Bu sorunu daha uzun süre çalışan madencilerin doğru olasılığı bulma ihtimalini arttırarak çözmeyi planlıyorsunuz gibi anladım. Bu %51 saldırı ihtimalini düşürebilir ancak ağ üzerinde uzun süredir çalışan bir madenci %51 saldırısı yapmaya karar verirse bir plan var mı ? Böyle bir saldırının maliyeti muhtemelen daha fazla olacak ama imkansız değil.

Bir de gerçek madencilerin kendi içerisinde farklı zincirlere yönelme olasılığını da yaratmış olmuyor musunuz ?

Öncelikle cevap verdiğiniz için teşekkür ederim. İkili hash sistemindeki rastgelelik kuralı nedeniyle saldırgan eğer madencilerin ne kadarı hangi hashi çözüyor bilgisini bilmiyorsa, çok büyük oranda saldırgan ikinci hashı dürüst madencilerden önce bulamıyor. Bu da consensusun bozulduğunu ve madencilerin iki blockchain üzerinde olduğunu gösteriyor bu durumda dürüst madenciler ağda dedikodu yaparak kendi zincirlerindeki işlemleri bulunduran ve üstüne daha fazla işlem barındıran blockchainlere geçiş yapıyorlar. Hiçbir madenci elinde tuttuğu işlemlerden vazgeçmiyor böylelikle olası bri consensus bozulması durumunda saldırgan isteğini yerine getiremiyor(saldrıgan normalde harcadığı bir parayı geri çevirmek istediği için bazı işlemleri silmeye çalışır). Ve bir süre sonra mining işlemlerine yeniden başlayan minerlar çoğunluk olarak doğru ve işlem kaybı olmayan incire yöneldiğinden bir sonraki mining sürecinde consensus bozulmuyor. Burda saldırgan tamamen kumar oynuyor eğer oranı atıp tutturamazsa tüm masrafı çöpe gidecek. Şuanda küçük zincirlerde bile bu masraf ciddi boyutlarda, ancak normal pow algoritmasında bu saldırıyı yapan kiş yüzde yüz başarılı olduğundan yapılan masrafa değiyor. Madenciler kendi aralarında protocol gereği işlem kaybı olmayan ve en çok işlem bulunduran zincire geçme eğiliminde olduğu için bir süre sonra bir zincir üzerinde çoğunluk uzlaşıyor. Yani madencilerin bir kaybı söz konusu değil. Daha uzun süre çalışan madencilerin doğru bulma olasılığını arttırmıyoruz, hatta madencilerin hiçbir oranını dokunmuyoruz ancak madencileri iki ye bölüp rastgele şekilde bir ona bir buna şeklinde dağıtıyoruz yani bazen madencilerin yüzde 70 i birinci hashı çözmek için uğraşırken yüzde 30 u ikini hash için uğraşıyor, bu oran tamamen rastgele her mandeci kendi seçimini yapıyor. Ayrıca saldırganın bilmesi gereken oranda bu yüzde oranı eğer yüzde 70 inin birinci hashe yüzde 30 unun ikinci hash ile uğraştığını bilseydi kendiside aynı oranı yaparak herkesden önce iki bloğuda bulmuş olurdu, ancak oranı bilmiyor bu yüzden tamamen atıp tutturması lazım, o kadar maliyette bu risk için çok tehlikeli.
14  Bitcoin / Development & Technical Discussion / Re: Next Generation Intelligent Consensus Algorithm | SPOW Consensus Algoritm on: February 26, 2021, 03:48:06 PM
At any rate nodes cannot know about a mined block until it is submitted using an RPC call. By then it wouldn't be too hard to add a bunch of small-sized junk transactions to a mined block's merkle tree and defeat the stopgap measure for when two blocks have different merkle roots.

When an attacker intends, it doesn't get anything because the protocol is designed so that each miner only passes to blockchains that have additional transactions to its own. Therefore, the transactions made cannot be reversed, that is, the attacker cannot reach the purpose of double spending.
15  Bitcoin / Development & Technical Discussion / Re: Next Generation Intelligent Consensus Algorithm | SPOW Consensus Algoritm on: February 26, 2021, 01:23:02 PM
There is an implementation difficulty in the SPOW picture. You say that large mining pools shouldn't reuse nonces of other large mining pools. But how are you going to strictly define "large" to something the protocol understands? How will you differentiate between mining pools, and miners (at the protocol level!) who are possibly using the same mining software?

Remember that this algorithm has to make it just as fair for tiny miners to find a block as it is for a miner with say 90% of the global hashrate. Since there are two hashes to be found and a miner has to pick one of them to find, it only takes two different miners like two S19's to find both hashes, since there is no protocol-level distance between mining pools and solo miners.

First of all thank you for your comment


At the protocol level, large pools will follow the process of finding a hash to determine which nonce range will run, for example if the nonce is 500 and there is a pool among 400 600, that nonce will be found at normal speed. But if there were more miner pools operating in the 400 600 range, that means more power and that nonce would be found faster. In other words, pools can find the nonce range they will work in this way. Another way is for miner pools to clearly state this range, if the miner pools explicitly say this information will not lose anything, even more will get more because no more competitors will come in this nonce range, and new pools that know this information will choose another nonce range that suits them. This actually looks like this; There is a mine field in the middle and everyone is looking for the mine by buying some area from this field. The benefit of doing it this way is that honest miners work as if the total hash power is the same. If we were not using the normal mining system like this, the total hash power of honest miners would be divided.For example, if the total hash power is 100 and the number of large miner pools is 10, our hash power is actually 10 because all of the miners start from the same nonce. This means repeating the same job, and as a result, the union of forces is broken. If we distribute the nonce intervals in a certain order, as I said, we combine all our power.


The purpose of the two hash systems is to detect a potential attack or ofspring blockchain excess. If there is a baby chain enough to divide the miners into two, the merkle root in the hash found by the miners defending the a blockchain and the merkle root in the hash that the miners defending the b chain will find will not be the same. In this situation, a rumor process is started in order to stabilize the network. This can be called a kind of voting. However, no miner tries to do this without giving up the transactions they have. Another possibility is the 51 percent attack, if the attacker uses the hash power and targets the first or the second hash, or both are powerful for a certain amount of time, here the majority of miners choose the first hash as honest miners randomly choose which hash to try to find, and if the attacker has that. Honest miners will surely find a hash if the majority cannot guess correctly in percentage terms. In this case, as the miners find a hash, the attacker's block chain is on a rival chain, and in this case, the network enters the process of finding the right chain and rumor again, honest miners will not accept the attacker's incomplete chain, as the attacker wants to delete the existing transactions. , and all efforts of the attacker will be wasted So is there no probability the attacker won? There is, but very unlikely. The attacker needs to be able to find all the hashes to win, so that it is not a rival blockchain. He can only do this if he correctly predicts the dispersion rate of honest miners, but if the attacker is very strong (eg 80 percent) he can win, even if he knows the dispersion rate of honest miners with a bit of error. However, remember that 100 percent of the attackers wins when the cost of 51 attacks today is covered, there is always a risk for the attacker in this algorithm, and a high amount.




16  Local / Proje Geliştirme / Yeni bir Consensus Algoritması | SPOW on: February 26, 2021, 09:59:42 AM
Arkadaşlar bu konudaki görüşlerinizi almak istiyorum, Şuanda uygulandığında 51 saldırılarına çok büyük oranda engelliyor, çünkü içindeki rastgelelik unsuru nedeniyle saldrıının başarılı olma ihitmalı bilinmeyen saldırıları tek seferde tutturma üzerine. bu da saldırıyı çok zor ve maliyeti riske atılamayacak hale getiriyor.

Anlatıcı Resim:
https://raw.githubusercontent.com/onuratakan/SPOW/main/What%20is%20the%20SPOW.png

PDF:
https://github.com/onuratakan/SPOW/blob/main/SPOW.pdf

Github:
https://github.com/onuratakan/SPOW
17  Bitcoin / Development & Technical Discussion / Next Generation Intelligent Consensus Algorithm | SPOW Consensus Algoritm on: February 26, 2021, 09:39:46 AM
I would like to discuss this consensus algorithm with anyone who understands these algorithms. This idea has a mozilla public license so feel free to share it.

Illustrative Picture:


PDF:
https://github.com/onuratakan/SPOW/blob/main/SPOW.pdf

Main Github Repository:
https://github.com/onuratakan/SPOW
18  Bitcoin / Development & Technical Discussion / Re: **** Solution for biggest security problem of pow, 51 attact, Safe Proof of Work on: February 25, 2021, 08:33:05 PM
19  Bitcoin / Development & Technical Discussion / Re: **** Solution for biggest security problem of pow, 51 attact, Safe Proof of Work on: February 25, 2021, 07:27:31 AM
I have released a new update that includes what will happen if the consensus breaks, now the miners will move from complexity to order when the consensus breaks. This way, in the next try, honest miners will agree on a block as a majority. Attackers, on the other hand, will most likely leave the game as they do not bear the costs.
20  Bitcoin / Development & Technical Discussion / Re: **** Solution for biggest security problem of pow, 51 attact, Safe Proof of Work on: February 24, 2021, 10:15:29 PM
Someone enlightened me about mining pools and this consensus algorithm, I prepared a pdf with a solution for it and sent it to the repo, Please help to disseminate and discuss this idea.

Thanks and best regards
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!