Опасная ошибка в текущем клиенте

В немецкой части форума в настоящее время мы обсуждаем очень тонкими, опасно ошибка в графическом интерфейсе.

Если ввести в 0,005 сумма для отправки, клиент посылает 5,00

Для США только локализованных парней я должен добавить: 0005 есть, например, в Германии естественный путь к типу, что в США будет набран 0.005 - и это согласуется со всеми видами локализаций в операционной системе.

Таким образом, немецкий пользователь может послать гораздо более высокую сумму, чем она собиралась.

У нас есть ошибка, подтвержденное на 0.3.23 бета-клиент на Windows 7 с помощью Dennis1234 и на 0.3.23 бета-клиента на Linux самостоятельно компилированию mself. Так как мой клиент работает в testnet в настоящее время я сделал некоторые испытания:

0,0005 анализируется как "ошибка в количестве"
0005 является перегенерироваться, как 5,00
0,05 производит "ошибка в количестве"
0,5 производит "ошибка в количестве"

Перегенерироваться в 5.00 означает следующее:

Я вхожу 0005 и на "послать" отображаемое количество изменений в 5.00, и я получаю сообщение об ошибке на нехватке средств (у меня нет 5 BTC в моем текущем счете testnet). От нормального поведения клиента я полагаю, что, если у меня было больше, чем 5,00 я бы просто потерять эти 5.00.

Я не в программировании WxWidgets иначе я бы сделать это сам. Я думаю, что это очень важно, что мы получаем, что фиксированные как можно скорее!

Полезная информация Dev:

Ошибка в SRC / util.cpp: ParseMoney. В частности, линия 375 функция явно проверяет «» и интерпретирует его как американский / английский (или другой?) символ групп разрядов. Он проверяет, есть ли цифра перед запятой, а три цифры после него (например, один миллион долларов можно записать в виде $ 1 млн).

Из-за этого 0,005 считается действительным, даже если он не имеет никакого смысла, даже с точки зрения цифра группировки. Я бы сказал, что несколько патчей в порядке:

1) 0005 не считается действительным, если интерпретировать как значного группировки
2) ParseMoney должен быть чувствительным локали
3) OnButtonSend должен отображать действительное оно интерпретируется (после строки 1925, nValue) и запросить подтверждение.

3 необходимо потому, что ошибки, как это, скорее всего, возникают в течение длительного времени, и это просто все вокруг хорошая идея, чтобы дать пользователю второй шанс проверить свой вклад.

Кроме того, как упоминалось кем-то в немецком подфоруме, мы могли бы разделить поле ввода в 2 поля ввода с фиксированным или. между ними.

Я не знаю, если ThreadSafeMessageBox является безопасным для использования внутри CSendDialog :: OnButtonSend, внутри cs_sendlock критического блока. Настоящий Bitcoin DEV будет делать тяжелую там Но для чего это стоит, я написал следующее экспромтом:

Код:

BOOL ThreadSafeConfirmSendMoney (int64 nAmount, Const строка& strDestination, Const строка& strCaption, wxWindow * родитель)
{
	если (fDaemon)
		возвращает истину;
	
	Строка strMessage = strprintf (
        _ ("Собираясь Отправить% s в% s."
          "Это верно?"),
        FormatMoney (nAmount) .c_str (), strDestination.c_str ());
	
	Возвращение (ThreadSafeMessageBox (strMessage, strCaption, wxYES_NO, родитель) == wxYES);
}

и потенциально может быть вызван после проверки nValue, перед разбором адрес Bitcoin, так как:

Код:

если (! ThreadSafeConfirmSendMoney (nValue, strAddress, _ ("Посылка ..."), это))
{
	вернуть;
}

Сообщается также Выпуск № 330:
https://github.com/bitcoin/bitcoin/issues/330

Я связывал этот пост на форуме для разработчиков.

Цитата: fpgaminer 19 июня 2011, 12:01:24 AM

3 необходимо потому, что ошибки, как это, скорее всего, возникают в течение длительного времени, и это просто все вокруг хорошая идея, чтобы дать пользователю второй шанс проверить свой вклад.

Да!
Я был в шоке, когда я впервые увидел, что сделка была сгенерирована без подтверждения.

Edit: даже bitcoind отправить * должен запрашивать подтверждение каким-то образом, и использовать порядковые номера для предотвращения катастроф в случае дублированных или сквозными вызовов.

Почему бы не использовать уже существующие помощник вместо того, чтобы изобретать колесо?

http://docs.wxwidgets.org/trunk/classwx_number_formatter.html

По крайней мере, один разработчик клиента Satoshi в прошлом заявило, что они намеренно стандартизированы форматирование на "НАС" форма, в идеале устранить проблемы неоднозначности. Если это должно быть дело, "0005" следует, вероятно, ошибка (т.е., запретить ведущие нули)

Цитата: Лука-младший 19 июня 2011 года, 5:56:55 PM

Это будет по-прежнему позволяют такие вещи, как 5005, который затем будет прочитан в 5005.

Я, со своей стороны, считаю, что даже с учетом значной группировки не мудро, и запятая может быть запрещена полностью (чтобы избежать неоднозначностей для людей, желающих использовать значную группировку).

Я также наткнулся на это во время разработки моего Qt GUI. Сначала я сделал это использовать стандартные функции номера парсинга Qt, которые принимают локаль во внимание. Потом я заметил, что официальный клиент явно по умолчанию формат числа США (что имеет смысл для единообразия), так просто я взял, что более.

Цитата: randomguy7 19 июня 2011, 12:07:16 AM

Я думал об этом, а также. Просто заставить «» в середине и рассматривать его как два поля, одно выравнивание по правому краю, а другой по левому краю. Нажатие «» в то время как в первом поле будет переходить к второму полю.

Я собираюсь осуществить это и является ли это полезным.

Цитата: Джон Смит на 19 июня 2011 года, 7:09:38 PM

Лучше всего делать ИМХО. Большой!

Цитата: de_bert от 19 июня 2011 года, 6:28:00 PM

Я, со своей стороны, считаю, что даже с учетом значной группировки не мудро, и запятая может быть запрещена полностью (чтобы избежать неоднозначностей для людей, желающих использовать значную группировку).

Согласен; Я думаю, что позволяет запятые в цифрах это Bitcoin GUI неправильно функция.

Я не думаю, фиксируя ввод номера в США обозначения только хорошее решение для программного обеспечения, предназначенная для использования за пределами США также. Числа должны быть введены в том же формате, они вводятся во все другом программном обеспечении на компьютере пользователя, и это зависит от местности.

Я не понимаю, почему это может быть какой-либо озабоченности или причины для любого обсуждения на всех, есть стандартные библиотечные функции для разбора строки, поплавки и формат плавает в строки в соответствии с локали пользователя. Они просто должны быть использованы, так же, как и все другое программное обеспечение использует их. Я не вижу, где проблема.

Также локали на компьютере может быть установлено неправильно, так вот в плохую идею тоже.

Я думаю, что лучшая идея будет:
Запрещает несколько, /. полностью.
Разрешить только один сингл или. в количестве, и рассматривать его в качестве десятичной запятой.

так:
1 000 = посылает один BTC
1,000 = посылает один BTC
1000000 = недействителен
1.000.000 = недействителен
1.000,000 = недействителен
1,000.000 = недействителен
0,1 = отправляет одной десятой BTC
0,1 = посылает одну десятую из BTC

То гораздо лучше, так как, если США лицо accidentially ввести, например, 3000 в качестве значной группировки отправить три tousands БТДА, что потерпит неудачу на "хорошо" сторона, поскольку только 3 BTC отправлено. Человек может Исли исправить это, посылая 2997 BTC больше.

Так вот хорошее исправление этой ошибки.
Я думаю, что с помощью локалей функции может быть опасны в финансовом программном обеспечении вообще, представьте себе человек, который устанавливает американскую версию окон или представить себе шведский человек приезжает в США интернет-кафе с флешкой с Bitcoin на нем.

Там еще одна причина, почему мы не можем использовать встроенный в разборе функции Qt / Wx: целые числа для точности, количества монет не двойники, но с фиксированной точкой.

Я согласен с ГА, количество группировки символы должны быть отключены при вводе номера. Он должен либо быть автоматическим или вообще не используется. Там нет причин, чтобы вручную вводить их.

Для целей отображения, с другой стороны, они являются полезными, поскольку они помогают в подсчете нулей.

котировка

Разрешить только один сингл или. в количестве, и рассматривать его в качестве десятичной запятой.

Или еще лучше: использовать решение два-поля, и сделать так, и. перейти ко второму полю. Это дает понять пользователю, что десятичные вводятся.

Редактировать: Я только что совершил это в Bitcoin-QT

Это, кажется, укрепить мнение, что необходимо перенести десятичную точку ...

https://github.com/bitcoin/bitcoin/pull/379

Я думаю, что это достаточно важно включить в 0.3.24rc2.

Цитата: Dansker от 20 июня 2011 года, 6:20:23 PM

Это, кажется, укрепить мнение, что необходимо перенести десятичную точку ...

Согласен. Если десятичная точка не обрабатывается свойство (перенесено) Bitcoin никогда не взлетит. Идеальным решением было бы переместить его на два места сейчас и переместить его на одно место в то время, после того, что (чтобы сохранить значение всегда стоит меньше доллара). Адекватное решение было бы переместить все пути, так что не существует такого понятия, как дробное Bitcoin.

Цитата: hello_good_sir от 04 июля 2011 года, 3:08:10 PM

При увеличении стоимости в год 50%, $ 1 будет равен минимальному значению Bitcoin в 26 лет.

Предпринимались ли рассмотрение этого? Ofc, непохоже, что он будет продолжать увеличиваться на эту сумму в год.

21 миллионов бит монет на 100 миллионов единиц = $ 2100 трлн, что намного больше, чем мировой ВВП.

Число, если в 64-битовое число, но резервные биты означают, что он может пойти выше, чем ниже.

Цитата: Гэвин Андресен 04 июля 2011 года, 1:51:43 PM

https://github.com/bitcoin/bitcoin/pull/379

Я думаю, что это достаточно важно включить в 0.3.24rc2.

Благодаря Gavin, хорошая работа. Цените вашу преданность клиента.

18 июня 2011, 11:08:03 PM	# 1
При р Сообщения: 198 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Взлом Биткоин адресов. 500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome" Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e подробнее... Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru В немецкой части форума в настоящее время мы обсуждаем очень тонкими, опасно ошибка в графическом интерфейсе. Если ввести в 0,005 сумма для отправки, клиент посылает 5,00 Для США только локализованных парней я должен добавить: 0005 есть, например, в Германии естественный путь к типу, что в США будет набран 0.005 - и это согласуется со всеми видами локализаций в операционной системе. Таким образом, немецкий пользователь может послать гораздо более высокую сумму, чем она собиралась. У нас есть ошибка, подтвержденное на 0.3.23 бета-клиент на Windows 7 с помощью Dennis1234 и на 0.3.23 бета-клиента на Linux самостоятельно компилированию mself. Так как мой клиент работает в testnet в настоящее время я сделал некоторые испытания: 0,0005 анализируется как "ошибка в количестве" 0005 является перегенерироваться, как 5,00 0,05 производит "ошибка в количестве" 0,5 производит "ошибка в количестве" Перегенерироваться в 5.00 означает следующее: Я вхожу 0005 и на "послать" отображаемое количество изменений в 5.00, и я получаю сообщение об ошибке на нехватке средств (у меня нет 5 BTC в моем текущем счете testnet). От нормального поведения клиента я полагаю, что, если у меня было больше, чем 5,00 я бы просто потерять эти 5.00. Я не в программировании WxWidgets иначе я бы сделать это сам. Я думаю, что это очень важно, что мы получаем, что фиксированные как можно скорее!

19 июня 2011, 12:01:24 AM	# 2
fpgaminer Сообщения: 560 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Получил 1806 Биткоинов Реальная история. Полезная информация Dev: Ошибка в SRC / util.cpp: ParseMoney. В частности, линия 375 функция явно проверяет «» и интерпретирует его как американский / английский (или другой?) символ групп разрядов. Он проверяет, есть ли цифра перед запятой, а три цифры после него (например, один миллион долларов можно записать в виде $ 1 млн). Из-за этого 0,005 считается действительным, даже если он не имеет никакого смысла, даже с точки зрения цифра группировки. Я бы сказал, что несколько патчей в порядке: 1) 0005 не считается действительным, если интерпретировать как значного группировки 2) ParseMoney должен быть чувствительным локали 3) OnButtonSend должен отображать действительное оно интерпретируется (после строки 1925, nValue) и запросить подтверждение. 3 необходимо потому, что ошибки, как это, скорее всего, возникают в течение длительного времени, и это просто все вокруг хорошая идея, чтобы дать пользователю второй шанс проверить свой вклад.

19 июня 2011, 12:07:16 AM	# 3
randomguy7 Сообщения: 528 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Кроме того, как упоминалось кем-то в немецком подфоруме, мы могли бы разделить поле ввода в 2 поля ввода с фиксированным или. между ними.

19 июня 2011, 12:12:35 AM	# 4
fpgaminer Сообщения: 560 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Я не знаю, если ThreadSafeMessageBox является безопасным для использования внутри CSendDialog :: OnButtonSend, внутри cs_sendlock критического блока. Настоящий Bitcoin DEV будет делать тяжелую там Но для чего это стоит, я написал следующее экспромтом: Код: BOOL ThreadSafeConfirmSendMoney (int64 nAmount, Const строка& strDestination, Const строка& strCaption, wxWindow * родитель) { если (fDaemon) возвращает истину; Строка strMessage = strprintf ( _ ("Собираясь Отправить% s в% s." "Это верно?"), FormatMoney (nAmount) .c_str (), strDestination.c_str ()); Возвращение (ThreadSafeMessageBox (strMessage, strCaption, wxYES_NO, родитель) == wxYES); } и потенциально может быть вызван после проверки nValue, перед разбором адрес Bitcoin, так как: Код: если (! ThreadSafeConfirmSendMoney (nValue, strAddress, _ ("Посылка ..."), это)) { вернуть; }

19 июня 2011, 12:22:50 AM	# 5
Роб П. Сообщений: 84 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Сообщается также Выпуск № 330: https://github.com/bitcoin/bitcoin/issues/330 Я связывал этот пост на форуме для разработчиков.

19 июня 2011, 12:42:16 AM	# 6
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: fpgaminer 19 июня 2011, 12:01:24 AM 3 необходимо потому, что ошибки, как это, скорее всего, возникают в течение длительного времени, и это просто все вокруг хорошая идея, чтобы дать пользователю второй шанс проверить свой вклад. Да! Я был в шоке, когда я впервые увидел, что сделка была сгенерирована без подтверждения. Edit: даже bitcoind отправить * должен запрашивать подтверждение каким-то образом, и использовать порядковые номера для предотвращения катастроф в случае дублированных или сквозными вызовов.

19 июня 2011, 3:02:19 PM	# 7
prof7bit Сообщения: 672 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Почему бы не использовать уже существующие помощник вместо того, чтобы изобретать колесо? http://docs.wxwidgets.org/trunk/classwx_number_formatter.html

19 июня 2011, 5:56:55 PM	# 8
Luke-Jr Сообщения: 2282 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте По крайней мере, один разработчик клиента Satoshi в прошлом заявило, что они намеренно стандартизированы форматирование на "НАС" форма, в идеале устранить проблемы неоднозначности. Если это должно быть дело, "0005" следует, вероятно, ошибка (т.е., запретить ведущие нули)

19 июня 2011, 6:28:00 PM	# 9
de_bert Сообщений: 45 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: Лука-младший 19 июня 2011 года, 5:56:55 PM По крайней мере, один разработчик клиента Satoshi в прошлом заявило, что они намеренно стандартизированы форматирование на "НАС" форма, в идеале устранить проблемы неоднозначности. Если это должно быть дело, "0005" следует, вероятно, ошибка (т.е., запретить ведущие нули) Это будет по-прежнему позволяют такие вещи, как 5005, который затем будет прочитан в 5005. Я, со своей стороны, считаю, что даже с учетом значной группировки не мудро, и запятая может быть запрещена полностью (чтобы избежать неоднозначностей для людей, желающих использовать значную группировку).

19 июня 2011, 7:09:38 PM	# 10
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Я также наткнулся на это во время разработки моего Qt GUI. Сначала я сделал это использовать стандартные функции номера парсинга Qt, которые принимают локаль во внимание. Потом я заметил, что официальный клиент явно по умолчанию формат числа США (что имеет смысл для единообразия), так просто я взял, что более. Цитата: randomguy7 19 июня 2011, 12:07:16 AM Кроме того, как упоминалось кем-то в немецком подфоруме, мы могли бы разделить поле ввода в 2 поля ввода с фиксированным или. между ними. Я думал об этом, а также. Просто заставить «» в середине и рассматривать его как два поля, одно выравнивание по правому краю, а другой по левому краю. Нажатие «» в то время как в первом поле будет переходить к второму полю. Я собираюсь осуществить это и является ли это полезным.

19 июня 2011, 9:19:51 PM	# 11
гИМ Сообщений: 90 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: Джон Смит на 19 июня 2011 года, 7:09:38 PM Я думал об этом, а также. Просто заставить «» в середине и рассматривать его как два поля, одно выравнивание по правому краю, а другой по левому краю. Нажатие «» в то время как в первом поле будет переходить к второму полю. Я собираюсь осуществить это и является ли это полезным. Лучше всего делать ИМХО. Большой!

20 июня 2011, 1:39:32 AM	# 12
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: de_bert от 19 июня 2011 года, 6:28:00 PM Я, со своей стороны, считаю, что даже с учетом значной группировки не мудро, и запятая может быть запрещена полностью (чтобы избежать неоднозначностей для людей, желающих использовать значную группировку). Согласен; Я думаю, что позволяет запятые в цифрах это Bitcoin GUI неправильно функция.

20 июня 2011, 3:13:29 PM	# 13
prof7bit Сообщения: 672 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Я не думаю, фиксируя ввод номера в США обозначения только хорошее решение для программного обеспечения, предназначенная для использования за пределами США также. Числа должны быть введены в том же формате, они вводятся во все другом программном обеспечении на компьютере пользователя, и это зависит от местности. Я не понимаю, почему это может быть какой-либо озабоченности или причины для любого обсуждения на всех, есть стандартные библиотечные функции для разбора строки, поплавки и формат плавает в строки в соответствии с локали пользователя. Они просто должны быть использованы, так же, как и все другое программное обеспечение использует их. Я не вижу, где проблема.

20 июня 2011, 3:46:53 PM	# 14
Себастьян Сообщения: 122 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Также локали на компьютере может быть установлено неправильно, так вот в плохую идею тоже. Я думаю, что лучшая идея будет: Запрещает несколько, /. полностью. Разрешить только один сингл или. в количестве, и рассматривать его в качестве десятичной запятой. так: 1 000 = посылает один BTC 1,000 = посылает один BTC 1000000 = недействителен 1.000.000 = недействителен 1.000,000 = недействителен 1,000.000 = недействителен 0,1 = отправляет одной десятой BTC 0,1 = посылает одну десятую из BTC То гораздо лучше, так как, если США лицо accidentially ввести, например, 3000 в качестве значной группировки отправить три tousands БТДА, что потерпит неудачу на "хорошо" сторона, поскольку только 3 BTC отправлено. Человек может Исли исправить это, посылая 2997 BTC больше. Так вот хорошее исправление этой ошибки. Я думаю, что с помощью локалей функции может быть опасны в финансовом программном обеспечении вообще, представьте себе человек, который устанавливает американскую версию окон или представить себе шведский человек приезжает в США интернет-кафе с флешкой с Bitcoin на нем.

20 июня 2011, 3:47:28 PM	# 15
Wumpus Сообщения: 812 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Там еще одна причина, почему мы не можем использовать встроенный в разборе функции Qt / Wx: целые числа для точности, количества монет не двойники, но с фиксированной точкой. Я согласен с ГА, количество группировки символы должны быть отключены при вводе номера. Он должен либо быть автоматическим или вообще не используется. Там нет причин, чтобы вручную вводить их. Для целей отображения, с другой стороны, они являются полезными, поскольку они помогают в подсчете нулей. котировка Разрешить только один сингл или. в количестве, и рассматривать его в качестве десятичной запятой. Или еще лучше: использовать решение два-поля, и сделать так, и. перейти ко второму полю. Это дает понять пользователю, что десятичные вводятся. Редактировать: Я только что совершил это в Bitcoin-QT

20 июня 2011, 6:20:23 PM	# 16
Dansker Сообщения: 740 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Это, кажется, укрепить мнение, что необходимо перенести десятичную точку ...

4 июля 2011, 1:51:43 PM	# 17
Гэвин Андресен Сообщения: 1652 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте https://github.com/bitcoin/bitcoin/pull/379 Я думаю, что это достаточно важно включить в 0.3.24rc2.

4 июля 2011, 3:08:10 PM	# 18
hello_good_sir Сообщения: 686 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: Dansker от 20 июня 2011 года, 6:20:23 PM Это, кажется, укрепить мнение, что необходимо перенести десятичную точку ... Согласен. Если десятичная точка не обрабатывается свойство (перенесено) Bitcoin никогда не взлетит. Идеальным решением было бы переместить его на два места сейчас и переместить его на одно место в то время, после того, что (чтобы сохранить значение всегда стоит меньше доллара). Адекватное решение было бы переместить все пути, так что не существует такого понятия, как дробное Bitcoin.

4 июля 2011, 3:39:29 PM	# 19
TierNolan Сообщения: 1148 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: hello_good_sir от 04 июля 2011 года, 3:08:10 PM Согласен. Если десятичная точка не обрабатывается свойство (перенесено) Bitcoin никогда не взлетит. Идеальным решением было бы переместить его на два места сейчас и переместить его на одно место в то время, после того, что (чтобы сохранить значение всегда стоит меньше доллара). Адекватное решение было бы переместить все пути, так что не существует такого понятия, как дробное Bitcoin. При увеличении стоимости в год 50%, $ 1 будет равен минимальному значению Bitcoin в 26 лет. Предпринимались ли рассмотрение этого? Ofc, непохоже, что он будет продолжать увеличиваться на эту сумму в год. 21 миллионов бит монет на 100 миллионов единиц = $ 2100 трлн, что намного больше, чем мировой ВВП. Число, если в 64-битовое число, но резервные биты означают, что он может пойти выше, чем ниже.

5 июля 2011, 12:43:09 PM	# 20
Роб П. Сообщений: 84 Цитировать по имени цитировать ответ	Re: Опасные ошибки в текущем клиенте Цитата: Гэвин Андресен 04 июля 2011 года, 1:51:43 PM https://github.com/bitcoin/bitcoin/pull/379 Я думаю, что это достаточно важно включить в 0.3.24rc2. Благодаря Gavin, хорошая работа. Цените вашу преданность клиента.

Заголовок