Работа с tx.* в mempool и blocktemplate

[info_infoman]

подскажите если я назначаю переменной tx.******
некое значение, означает ли это автоматическое изменение этого значения в транзакции?

тобишь в локальном майнере main.cpp происходит перебор транзакций mempool в цикле создания blocktemplate
куда подгружаются параметры транзакции
вопрос если я на лету присваиваю этим параметрам некое значение, будут ли эти изменения записаны в mempool(временное хранилище транзакций) если например транзакция временно не принимается в blocktemplate

вообще задача помечать некоторые транзакции и откладывать их принятие в blocktemplate на некоторый период времени без использования дополнительных регистров

[bee7]

Либо вы проигрываете в скорости, либо в памяти. Других вариантов нет. В первом случае, вы каждый раз принимая решение о включении транзакции в ответ getblocktemplate производите соответствующую проверку. Во втором - вы либо ведете отдельные списки того, что отложено и того, что уже проходило проверку, либо заводите доолнительный несериализуемый элемент данных в классе CTransaction, в котором всё что нужно и храните. Изменять те данные, которые сериализуются, я бы не советовал, так как в случае некорректного восстановления их исходных значений транзакция перестанет быть валидной в подавляющем большинстве случаев.

[info_infoman]

Либо вы проигрываете в скорости, либо в памяти. Других вариантов нет. В первом случае, вы каждый раз принимая решение о включении транзакции в ответ getblocktemplate производите соответствующую проверку. Во втором - вы либо ведете отдельные списки того, что отложено и того, что уже проходило проверку, либо заводите доолнительный несериализуемый элемент данных в классе CTransaction, в котором всё что нужно и храните. Изменять те данные, которые сериализуются, я бы не советовал, так как в случае некорректного восстановления их исходных значений транзакция перестанет быть валидной в подавляющем большинстве случаев.

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

[Sheogorath]

нода жертвуя памятью

...хранит id транзакции как строку, текстовое представление хеша ))

[bee7]

нода жертвуя памятью

...хранит id транзакции как строку, текстовое представление хеша ))

Это если извращаться. ОП не писал, что он хранит id в тектовом представлении. Стандартно все хеши хранятся как uint256, т.е. по крайней мере в два раза меньше. В случае мем-пул транзакций можно было бы ограничиться и списком указателей, нужно только тщательно всё прописать.

[info_infoman]

недолго там туда сюда преобразовывать - .tostring().s_str() и всего делов то ... (заточим потом)...

впрочем раз уж пошла такая пьянка
подскажите что побыстрее будет

мне нужен универсальный много поточный асинхронный датчик состояния внешней среды (сокетов)
посоветуйте что взять?
multiCURL
libevent
или использовать то что уже есть в биткоин?

мне б попроще и поуниверсальней и побыстрее

гляжу в сторону multiCURL и в сторону net.cpp (биткоин)
прям не знаю что выбрать

задача как можно быстрее без задержек валидализировать состояние внешней среды со скоростью сопоставимой валидализации транзакций попадающих в mempool.

[bee7]

недолго там туда сюда преобразовывать - .tostring().s_str() и всего делов то ... (заточим потом)...

впрочем раз уж пошла такая пьянка
подскажите что побыстрее будет

мне нужен универсальный много поточный асинхронный датчик состояния внешней среды (сокетов)
посоветуйте что взять?
multiCURL
libevent
или использовать то что уже есть в биткоин?

мне б попроще и поуниверсальней и побыстрее

гляжу в сторону multiCURL и в сторону net.cpp (биткоин)
прям не знаю что выбрать

задача как можно быстрее без задержек валидализировать состояние внешней среды со скоростью сопоставимой валидализации транзакций попадающих в mempool.

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