Author

Topic: Один адрес на два кошелька и вопрос отката &# (Read 850 times)

full member
Activity: 216
Merit: 100
В официальном клиенте откаченные транзакции снова добавляются в memory pool.
main.cpp, функция SetBestChain, vResurrect - список "возрождаемых" транзакций:
Code:
    // Disconnect shorter branch
    list vResurrect;
    BOOST_FOREACH(CBlockIndex* pindex, vDisconnect) {
        CBlock block;
        ...
        if (!DisconnectBlock(block, state, pindex, view))
            return error("SetBestBlock() : DisconnectBlock %s failed", pindex->GetBlockHash().ToString().c_str());
        ...
        // Queue memory transactions to resurrect.
        // We only do this for blocks after the last checkpoint (reorganisation before that
        // point should only happen with -reindex/-loadblock, or a misbehaving peer.
        BOOST_REVERSE_FOREACH(const CTransaction& tx, block.vtx)
            if (!tx.IsCoinBase() && pindex->nHeight > Checkpoints::GetTotalBlocksEstimate())
                vResurrect.push_front(tx);
    }
    ...
    // Resurrect memory transactions that were in the disconnected branch
    BOOST_FOREACH(CTransaction& tx, vResurrect) {
        // ignore validation errors in resurrected transactions
        CValidationState stateDummy;
        if (!AcceptToMemoryPool(mempool,stateDummy, tx, false, NULL))
            mempool.remove(tx, true);
    }
hero member
Activity: 518
Merit: 500
Вот здесь, наверное, будет правильно такие вопросы задавать
https://bitcointalk.org/index.php?board=4.0
newbie
Activity: 14
Merit: 0
Quote
Блоки одновременно создают множество майнеров. Регулярно возникают ситуации, когда один и тот же блок является предыдущим для двух новых блоков. В каждом из новых блоков могут встречаться как одинаковые транзакции, так и разные, то есть вошедшие только в один из них. Через некоторое время появляются очередные блоки, цепочка может раздвоиться. Каждая из ветвей равноправна до тех пор, пока одна из них не получит более длинное продолжение. Обычно, при равенстве длины, предпочтение отдаётся той цепочке, конечный блок которой появился раньше. Система автоматически легитимной считает более длинную цепочку, не обращая внимание на время создания последнего блока. Транзакции, вошедшие исключительно в менее длинную ветку (в том числе по выплате вознаграждения), теряют статус подтверждённых. Если это транзакция по передаче биткоинов, то она может быть включена в очередной блок.

Меня смущает необязательность употреблённого слова "может". Я в общем не против перепровести какие-то транзы если что-то отменилось, но мне надо понять как автоматически детектировать такую ситуацию и понять текущее состояние, чтобы программа могла принять решение.

Подскажите правильный раздел форума, где мне смогут дать ответ. И, кстати, смогули я в него написать? Smiley
newbie
Activity: 14
Merit: 0
По второму вопросу, вы читали полуофициальную вики? В частности, статью Block chain

Мне казалось, что по моему вопросу должно быть понятно, что это то как раз я прочитал.
Quote
Блоки одновременно создают множество майнеров. Регулярно возникают ситуации, когда один и тот же блок является предыдущим для двух новых блоков. В каждом из новых блоков могут встречаться как одинаковые транзакции, так и разные, то есть вошедшие только в один из них. Через некоторое время появляются очередные блоки, цепочка может раздвоиться. Каждая из ветвей равноправна до тех пор, пока одна из них не получит более длинное продолжение. Обычно, при равенстве длины, предпочтение отдаётся той цепочке, конечный блок которой появился раньше. Система автоматически легитимной считает более длинную цепочку, не обращая внимание на время создания последнего блока. Транзакции, вошедшие исключительно в менее длинную ветку (в том числе по выплате вознаграждения), теряют статус подтверждённых. Если это транзакция по передаче биткоинов, то она может быть включена в очередной блок.

Меня смущает необязательность употреблённого слова "может". Я в общем не против перепровести какие-то транзы если что-то отменилось, но мне надо понять как автоматически детектировать такую ситуацию и понять текущее состояние, чтобы программа могла принять решение.

Quote
Я с RPC дело не имел, но по идее по умолчанию адрес берется из пула заранее сгенерированных адресов в кошельке, генерируется еще один и ставится в "конец очереди". Теоретически можно сделать что угодно, даже можно тот же самый адрес для остатка указать, как в Armory, например. Но здесь я не помощник уже, курите мануалы Smiley

Получив txid после вызова функции перевода, как я понимаю, я могу получить полную стркутуру транзакции и вычислить адрес, куда пришла сдача. Но мне проще этот адрес самому контролировать, чтобы знать где деньги.

P.S. вопрос в сторону. только новичкам нельзя постить чаще, чем 1 раз в 360 секунд? Бесит!
hero member
Activity: 518
Merit: 500
Касательно списывания всех монет на новый адрес -- он придумывается при выполнении команды sendmany автоматически? И получить его потом как? Или же можно придумать адрес самостоятельно и указать его получателем остатка перевода руками? Как-то вот эти вопросы обычно стороной в пополурной литературе, по большей части даются примеры для getinfo и всё.
Я с RPC дело не имел, но по идее по умолчанию адрес берется из пула заранее сгенерированных адресов в кошельке, генерируется еще один и ставится в "конец очереди". Теоретически можно сделать что угодно, даже можно тот же самый адрес для остатка указать, как в Armory, например. Но здесь я не помощник уже, курите мануалы Smiley

По второму вопросу, вы читали полуофициальную вики? В частности, статью Block chain
newbie
Activity: 14
Merit: 0
1. Да. Вот только при транзакции в официальном кошельке вроде списываются все монеты с адреса, а остаток идет на новый, так что тут внимательнее

Касательно списывания всех монет на новый адрес -- он придумывается при выполнении команды sendmany автоматически? И получить его потом как? Или же можно придумать адрес самостоятельно и указать его получателем остатка перевода руками? Как-то вот эти вопросы обычно стороной в пополурной литературе, по большей части даются примеры для getinfo и всё.

Quote
Второй вопрос я не понял Sad

Второй вопрос возникает из теории о том, что возможно развитие параллельных цепочек и в основную входит та, в которой работы выполнено больше. Мой вопрос в том, что случается с теми транзакциями, что были в отброшенной цепочке. По большей части, я думаю, они должны бы включиться в большую цепочку, но гарантии для отдельно взятой транзакции нет. И не совсем понял про поведение memory-pools, как долго они хранят непроведённые транзакции, ведь в большей цепочке могло не оказаться моей транзакции, допустим злобный майнер выкинул её, а в майнерах, сделавших меньшую цепочку с моей транзакцией, могло не остаться моей транзакции в пуле, поскольку они уже несколько блоков сделали после. В общем у меня тут путаница в голове, которая мешает понять всю модель.
member
Activity: 62
Merit: 10
Привет. Прошу прощения, если баян рваный, но я потратил уже несколько часов на поиск и чтение, так что имеют право спрашивать.

Вопрос 1.

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

Вопрос 2.

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

Вопрос 3.

Тут уж совсем ламерский, но пользуясь случаем спрошу. JSON-RPC: settxfee -- устанавливать надо перед каждой транзакцией или она запоминается клиентом (bitcoind -daemon) навсегда?

на третий вопрос она запоминается точно.
hero member
Activity: 518
Merit: 500
1. Да. Вот только при транзакции в официальном кошельке вроде списываются все монеты с адреса, а остаток идет на новый, так что тут внимательнее

Второй вопрос я не понял Sad
newbie
Activity: 14
Merit: 0
На третий свой вопрос сам нашёл ответ:
Code:
    Method: settxfee
    Parameters: (double amount)
    Description: Sets the default transaction fee for 24 hours (must be called every 24 hours).
    Returns: boolean
newbie
Activity: 14
Merit: 0
Люди, если никто не может ответить на эти вопросы тут, подскажите мне, где я могу их задать? На момент публикации вопроса я был полным новичком и больше нигде не мог писать, кроме как в этом разделе.
newbie
Activity: 14
Merit: 0
Привет. Прошу прощения, если баян рваный, но я потратил уже несколько часов на поиск и чтение, так что имеют право спрашивать.

Вопрос 1.

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

Вопрос 2.

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

Вопрос 3.

Тут уж совсем ламерский, но пользуясь случаем спрошу. JSON-RPC: settxfee -- устанавливать надо перед каждой транзакцией или она запоминается клиентом (bitcoind -daemon) навсегда?
Jump to: