Невозможно никому отправить монеты!?

[KanyT]

Тоже откатываюсь до 19. И, вероятно, как разберусь в коде, выпущу быстрый патч, который будет отменять это в любых последующих версиях.
Ибо некто охренел: за перевод 0.001 платить 0.01 я не буду, если у меня не "мешок мелочи".

Вот за это респект!

А могут кстати забанить в дальнейшем все старые клиенты? Если да, то подобный патч будет просто необходим.

[1713565372]

1713565372

[1713565372]

1713565372

[1713565372]

1713565372

[1713565372]

1713565372

[1713565372]

1713565372

[LZ]

Если будет уязвимость могут и забанить. Но ничто не мешает не отправлять информацию о версии.
Ведь система, по идее, должная развиваться с полной обратной совместимостью на уровне блоков.

[Vort]

сети не будет ничего хорошего от миллиона переводов по 1 наномонете, поэтому лимиты нужны
но поведение клиента всё же должно быть ясно и прозрачно - сейчас даже нельзя узнать полагается ли комиссия до нажатия кнопки "Отправить"

по поводу банов etc - софт пула просто не приймет транзакцию, если она ему не понравится

[Vort]

покопал немного код...

Code:

double dPriority = 0;
...
dPriority += (double)nCredit * pcoin.first->GetDepthInMainChain();
...
dPriority /= nBytes;
...
bool fAllowFree = CTransaction::AllowFree(dPriority);
...
static bool AllowFree(double dPriority)
{
  return dPriority > COIN * 144 / 250;
...

для бесплатной транзакции приоритет должен быть выше
100000000 * 144 / 250 = 57600000

если GetDepthInMainChain является количеством подтверждений,
то для 1 копейки приоритет будет вычисляться как
(1000000 * кол_подтверждений) / кол_байт

при количестве байт = 224, получается нужно 12903 подтверждений,
что эквивалентно 3 месяцам ожидания

где ошибка?

upd.
начинает проясняться суть тех констант...
250 - количество байт в "обычной" транзакции
144 - ждём день

получается, бесплатная "норма" - 1 BTC в день

upd2.
полагаю, при таком подходе может быть достигнута ровно противоположная цель
комиссия при транзакции - это приманка для майнера
соответственно, добавляя её к негодным/мелким/частым транзакциям,
мы делаем их обработку более приоритетной для пулов
и в итоге, при дефиците места в блоке, пулу выгоднее будет запечатать 0.01+0.01, чем 10.00+0.00