Один адрес на два кошелька и вопрос отката &#

[manbacher]

Привет. Прошу прощения, если баян рваный, но я потратил уже несколько часов на поиск и чтение, так что имеют право спрашивать.

Вопрос 1.

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

Вопрос 2.

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

Вопрос 3.

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

[manbacher]

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

[manbacher]

На третий свой вопрос сам нашёл ответ:

Code:

    Method: settxfee
    Parameters: (double amount)
    Description: Sets the default transaction fee for 24 hours (must be called every 24 hours).
    Returns: boolean

[Deth]

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

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

[jj101]

Привет. Прошу прощения, если баян рваный, но я потратил уже несколько часов на поиск и чтение, так что имеют право спрашивать.

Вопрос 1.

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

Вопрос 2.

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

Вопрос 3.

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

на третий вопрос она запоминается точно.

[manbacher]

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

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

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

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

[Deth]

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

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

По второму вопросу, вы читали полуофициальную вики? В частности, статью Block chain

[manbacher]

По второму вопросу, вы читали полуофициальную вики? В частности, статью Block chain

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

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

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

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

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

P.S. вопрос в сторону. только новичкам нельзя постить чаще, чем 1 раз в 360 секунд? Бесит!

[manbacher]

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

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

Подскажите правильный раздел форума, где мне смогут дать ответ. И, кстати, смогули я в него написать?

[Deth]

Вот здесь, наверное, будет правильно такие вопросы задавать
https://bitcointalk.org/index.php?board=4.0

[yurm]

В официальном клиенте откаченные транзакции снова добавляются в memory pool.
main.cpp, функция SetBestChain, vResurrect - список "возрождаемых" транзакций:

Code:

    // Disconnect shorter branch
    list<CTransaction> 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);
    }