text:
blockchain official documentation
I am developing a system of administrative management. The project is migrating from PHP to C ++. With the new requirements we want to work with blockchain. But when looking for more about it, despites generic tutorials, I almost always find links to blockchain implementations like Bitcoin or Eterium. But I need to implement something pure, from scratch.
Where can I find the official documentation of blockchain technology ??

"Blockchain technology" is as meaningless as "artificial intelligence" or "web 2.0". It refers to a collection of ideas, most of which are pure marketing hype. Some of those ideas are useful, but rarely standalone. If you think you need a "from scratch blockchain" without understanding the fundamental problems it solves (hint: not much!), I'm afraid you'll just waste your time.

I have found this https://readthedocs.org/projects/blockchain-guide/downloads/pdf/latest/

There is no official documentation. "blockchain technology" has no central authority nor anything official as it is just an abstract concept.

Where can I find the official documentation of blockchain technology

Nowhere. There is no official body in charge of "blockchain technology".
There are many different individuals, groups and organisations all doing their own "blockchain" work more or less independently. They will often base their blockchain partly on older blockchain ideas. Each of these groups may or may not publish a definition of the blockchain they are using.
One example is the Bitcoin Developer Reference written by some ever-changing random group of mostly anonymous/pseudonymous people whose motives and accuracy you have to make your own judgement about. I suspect they are mostly OK but you have no recourse if I or they are wrong misleading or even maliciously deceptive.
The nearest thing to an official definition would probably be Satoshi Nakamoto's white paper published in October 2008. If you read and understand that, you are well-placed to implement your own blockchain. You'll need a grounding in basic cryptographic principles and algorithms (don't write your own cryptographic algorithms).

we want to work with blockchain.

If this comes from marketing, ignore them and just add the word "blockchain" liberally to product names, documentation etc :-)
Note that The Economist Sept 1st 2018 has a 12-page section on blockchain
Although mostly positive about blockchain, it does have many cautions.

because of its decentralised nature, a blockchain will always be slower and more cumbersome than a standard database.

Their separate lead article says:

A few organisations, such as SWIFT, a bank payment network, and Stripe, an online payments firm, have abandonded blockchain projects, concluding that costs outweigh benefits. Most other projects are experimental.

The idea of replicated peer-to-peer databases with strong controls on integrity based on public-key cryptography goes back to at least 1984 when Ray Ozzie et-al formed Iris associates to develop Lotus Notes. Anyone selecting "blockchain" needs to have a deep understanding of which of it's characteristics are vital to their project, what alternatives exist and what the trade-offs are.

The simplest explanation of a blockchain is as a chain of cryptographically linked blocks of data.  Brett Benefield, Scott Herford, and Kyle Thomas write:
Each one of these blocks can have multiple pieces of information in it such as transaction information or asset data as an example. When a new block is added, it is added to the end of the chain of blocks and then a new hash value is computed. This relatively simple feature ensures that once the blockchain is large enough it is computationally secure preventing a malicious party from modifying any previous blocks. (Benefield, Herford and Thomas 2018, 1)
The blockchain is append only by design. An implementation feature maintains multiple copies of the blockchain, validated through a consensus mechanism. This increases the security of the blockchain, as a malicious actor would have to gain access to enough nodes and rewrite each blockchain quickly enough to achieve consensus that the altered chain is correct. To use Benefield, Herford, and Thomas’s term, this difficulty makes the distributed blockchain computationally secure.
The technology used to link the blocks of data is the cryptographic hash, which is a mathematical digest of a set of data. This cryptographic hash is the fingerprint of the block. It is impossible to use the cryptographic hash to determine the contents of the block, and it is impossible to change the block without altering the cryptographic hash.
A blockchain is a chain of cryptographically linked data blocks. The first block in a blockchain, known as the Genesis Block, is comprise of digital data and the cryptographic hash of that data. The next (and subsequent blocks) are comprised of the hash of the header of the previous block.
So what is a block, really? The block is a data structure called a container. The container consists of a header containing metadata (data about data) and the data itself. In the diagram above, the header contains only the hash of the previous block. To make the blockchain useful, we need define the data that can be contained within the block and the type of metadata used within the header.
There is no data structure endemic to the blockchain. A blockchain can be stored in a flat file or in a database. Because the blocks can be stored in any order, we need a way to identify the order of the blocks. For this, we add a timestamp. Next, according to Emmanuelle Anceaume (et al.), we also need a way to determine block validity.  The method used to determine validity in the Bitcoin network is proof of work.
Proof of work adds a nonce to the block. “A nonce is a random number that acts as a placeholder variable in mathematical functions.” (Stewart, Chapple and Gibson 2015) The proof of work involves replacing the nonce with random values and computing the cryptographic hash until you find one that satisfies a particular criteria. In the case of Bitcoin, the difficulty is to find a hash that begins with a particular number of zeroes, a goal that dynamically changes as the number of miners changes.
Finally, the transactions to be added to the block are stored in data structure called a Merkle Tree. (See below for more information.) This is a hash-based data structure that provides efficient storage and secure verification of the data. The result of all this is a blockchain.
Proof of Work is a consensus algorithm used to determine who gets to create the next block, and requires a majority of the nodes to agree. Very democratic, but reliant upon the size of the network to prevent fraud. There are other consensus algorithms used in different blockchain implementations, such as “Proof of Stake”, “Proof of Activity”, “Proof of Burn”, “Proof of Capacity”, and “Proof of Authority”. Each type of Byzantine fault tolerance is implemented differently by each implementation. Thus, once again, the infrastructure determines the system's resistance to Byzantine faults.
There are some other things you need to know.

The blockchain is a journal, not a ledger. A journal is a list of transactions; a ledger is an analyzed summary of the journal.
The blockchain is not inherently secure. It is basically a text file, and visible to everyone with a copy. Securing the blockchain is an implementation feature.
The blockchain is not immutable. There have been several cases where public blockchains have had to be rolled back. Unlike the transaction log in a database, rolling back the blockchain revises the historical record, changing the audit trail.
Blockchain is neither a specification nor a protocol. It is a set of concepts that can be implemented in a variety of fashions. Your use case sounds like a private, permissioned blockchain, in which case you should investigate Hyperledger.
Blockchain is not a database, at least not a terribly good one. Public blockchain implementations satisfy neither the ACID nor the BASE database properties. In particular, because the blockchain can be rolled back, in essence changing history, blockchains are not Durable. Blockchains place a premium on consistency over availability, which means they are not performant.

Good luck.


text:
How to find Values N and K given R,S and Z in ECDSA?
How to find Value N and K ? I have the values for R, S and Z.
for example these:
BigInteger R =("00d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1"));
BigInteger S =("0044e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e"));
BigInteger Z =("00c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e"));
BigInteger X  =("00c477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96"));

Now, how to get these:
BigInteger K =("007a1a7e52797fc8caaa435d2a4dace39158504bf204fbe19f14dbb427faee50ae"));
BigInteger N =("00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141"));

How to get the values K and N ?
I am confused about how to calculate it, can somebody tell me how it is done?

k and n are not values that you calculate. k is randomly generated while n is predefined by the curve parameters.
n is the order of the curve G. It is defined by the curve parameters for the secp256k1 curve which are defined here: http://www.secg.org/sec2-v2.pdf. In those parameters, n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.
k is a randomly generated integer that is used only once for a signature. It is known as the nonce and acts as a source of randomness. If the same k is used to sign two different messages with the same private key, the private key will be leaked.

sorry, I'm still confused with the parameter n, whether the parameter n is the support point FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F or what ???  for example i got R = 0x00656073615d18ef82d884366dfcf8f84fd1a95ee7ae431ad8f23a30f7ecc5489c
S =0x00705324ea8a6f796c9c38df621ee07fd86515308a33e1f5acf2d6ae436c4a67ba
Z=0x00264e4672395b1fe67c9c6a6787ad69490585bc45ee7a046593620b1c0ccafb56 but im can't calculate value K and N and X ?? I've tried many times but can't find the correct value ??                                       thanks for your helping me sir. @AndrewChow

I already told you what n is and it is not that. As I said in my answer, you do not calculate n or k. n is given to you by the parameters for secp256k1, and k is randomly generated. You cannot calculate them.

@MasNdoloxz+ as shown in SEC2, the number you quote here is 'p', the modulus of the underlying finite field F_p. Like a,b,G,n it is fixed as part of the definition of the curve and you do not compute it. (All the parameters were actually computed once, decades ago, following the process in SEC1 as modified by the Koblitz constraint, but it's neither necessary nor practical for you to re-do that computation.)

@AndrewChow im sorry, im newbie for this, but im always continue to study this. i just want know step by step from zero. so i need teacher for this. sorry my bad english, im from indonesia. one again, the point is prime G = fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f , N = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 . i need teacher for this thanksyou

@AndrewChow i need teacher step by step for secp256k1 and recovering PrivateKey used value R S Z this sounds impossible,
actually I already have a private key, only I want to test it.  I am interested in https://bitcoin.stackexchange.com/questions/25814/ecdsa-signature-and-the-z-value/32546#32546   from this question must be two different messages with the same private key. what about 1 message, can i recover?

@dave_thompson_085 oke thanksyou for help. but i'm still consufed hehehehe

G is not that value. It is the point defined in the sec2 pdf I linked in my answer. You cannot recover a private key from the same message signed with different k values. That would mean that ECDSA is broken. You can only recover the private key if the same k values are used in signing two different messages. As has been said multiple times, n is not a value you calculate, it is given to you.

@AndrewChow oke now i'm understand. thanksyou for help

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
What happens if I send a XRP transaction to a blank TAG when I was supposed to send to a specifc TAG?
I sent XRP to a blank TAG while I was supposed to send to the éxchange's TAG. The address is the one from the exchange but the TAG was left blank. The exchange says that they can't recover the money.
What happened to the money? Is it theoretically possible for the exchange to recover it? As I understood, a blank tag but rigth address will send the money to the exchange but not in the account of anyone.

Most exchanges configure their accounts so that attempts to transfer funds to them without a destination tag will fail. If this is the case, then the transaction would have failed and the XRP would still be in the sending account. Otherwise, the XRP was received by the exchange but they have no easy way to know what account to credit.

I suppose TAG is neccessary for identify user. Person will get XRP from you, when you specify his tag at transaction details. At situation when you will leave blank TAG field, then your money will be transfered to general account or will be lost. It is impossible to (easy) prove you are owner of account from which this transfer was been send, so anyone will not recover your money.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Bitfinex Api limit server or individual ip address
I'm using the Bitfinex API to create a website with prices of the cryptocurrencies on there. Their website says they have a 90 request limit per minute per ip address. Since I will be putting the website on a web server for everyone to access, will the limit be an individual ip address limit or server ip address limit?


text:
CScript to CPubKey or derive CPubKey from CScript
Please can someone advise if it is possible to derive the CPubKey from a CSript object? Provided i get it up with an address before hand,
I can use numerous functions to attain all the info from the CPubKey using functions, but can you make a CPubKey from a CSript?
Or are they too much chalk and cheese?
Thank you,
EDIT:
Following the first answer I've tried the below to no joy. The script returns totally empty:

CScript scriptPubKey1;
CBitcoinAddress address("L4VPgtoBtuxsYMgyrRvQRadSV1Y139TDfd");
scriptPubKey1.SetDestination(address.Get());

CScript::const_iterator it = scriptPubKey1.begin(); // or specifically, the location of the pubkey in the CScript object
opcodetype opcode;
std::vector<unsigned char> data;
scriptPubKey1.GetOp(it, opcode, data); // data now contains the byte vector

CPubKey pubkey3 = CPubKey(data);

What are you trying to do? Extract the key used in a script? Or deterministically randomly generate a key from the script? Do you want any relation between who can spend the script and who can spend the key?

I want to generate a pubkey in code based on an address. Allowing me to use this pubkey in transactions later on. A roundabout way of doing things but it works with what i'm trying to do.

@LeosSire You cannot get the public key from an address because addresses are either pubkey hash (p2pkh) or script hashes (p2sh) and you cannot reverse a hash.

@LeosSire I understand you want a "pubkey based on an address". But what does that mean? What are you trying to do? I have a feeling there is either an alternative solution to your problem, or an easier way of formulating it? What properties do you want that pubkey to have?

If I understand the question, I believe you can construct a CPubKey from a byte vector extracted from the CScript script like:
CScript::const_iterator it = script.begin(); // or specifically, the location of the pubkey in the CScript object
opcodetype opcode;
valtype data;

script.GetOp(iterator, opcode, data); // data now contains the byte vector
CPubKey pubKey = CPubKey(data);


text:
Becoming Bitcoin wallet provider from scratch
I want to launch a bitcoin wallet service website for creating new wallets.
And i want to provide a tool for user for importing their old wallets using public and private key.
I know i can use some API's like blockchain.info api and some others
But they just allow to create wallets in their system , and you can not import other wallets using their api in your account.
How can i be a bitcoin wallet service provider from scratch?
i want to let my clients create new account with new wallet address + import and exporting wallets using public and private key + send & recieve money with other wallets + etc

Please +1 question if you don't know too

There is a standard Wallet Import Format (WIF): https://bitcoin.org/en/developer-guide#term-wallet-import-format utilized by the bitcoin core wallet with importprivkey and dumpprivkey

@JBaczuk thanks , do you know there any easier way or API? the document does not seem friendly for development.

what language are you coding in?

An API that lets you import private keys is very likely to be a scam.

@MCCCS, but what about https://bitcoin.org/en/developer-reference#importprivkey ?

@JBaczuk php is my default

If you have to ask you shouldn't be doing it


text:
Proof of work: average number of tries to create a block
First, I'm sorry if I'm asking a stupid question. I'm just trying to understand bitcoin. I'm reading the Ethereum white paper, and I couldn't understand this sentence about proof of work:

At the current target of ~2^187, the network must make an average of
  ~2^69 tries before a valid block is found

My question: how the 2^69 number of tries is computed?

Updated:
My question: why 2^69 instead of 2^70 or 2^169?

Are you asking how to determine the number of tries required to solve a block given a difficulty target? Or are you asking what physical operations take place in order for a miner to "try" to solve a block?

The 69 is just 256-187 because the hashes are 256 bits long

As MeshCollider's comment mentions, it is simply the difference between the total number of bits against the target bits.
As to why it is this way is just a function of probability. If you have a range of 1-100, and your target is <= 20, there are 20 numbers that satisfy your requirement. Thus, 20 * 1/100, or 20 tries out of 100 should result in a valid  number against your target.
It works the same way, although on a much larger scale here. Your target and attempt are both 256 bits numbers, which means they range from 0 to 2^256-1. If your target is 2^179, it means that 256-179, or 2^67 tries will, on average, produce a valid number against the target.


text:
How does Electrum wallet list my transaction record?
I'm a beginner of Bitcoin and blockchain. I use Electrum as my BitCoin wallet, and install it on both home PC and office PC.
I can see all transaction records on Electrum wallet of both home PC and office PC.
You know a new receiving address will be generated when I require a new  receiving bitcoin every time. I think that the new receiving address is generated  randomly.
I think that Electrum wallet will not record all receiving address I used.
so I'm very stranger that how Electrum wallet find my transaction records from  blockchain quickly, could you tell me?
A bad way is to calculate all private key based seed, and calculate all public key and my receiving bitcoin address based private key, then find all transaction based all my receiving bitcoin address from blockchain. it's a huge work!

Electrum is backed by a number of electrum-servers (electrumx is a more recent implementation). These servers maintain the full utxo set, and also serve information such as block headers to electrum clients.
Since both your electrum installations are using the same seed, they will always generate the same addresses.
When you start electrum, it will contact an electrum server to retrieve the latest blockchain information. It will then utilize a simplified payment verification (SPV) system to query the node for transactions relating to your addresses. As it realizes addresses have been used, it will generate more addresses using the seed words.
The process of how addresses are created from a common root is described in BIP32. The SPV protocol is described in the whitepaper, and also by MultiBit (another wallet that utilized SPV systems)

Thanks! Do you mean that electrum server will record all receiving address I used?

And if electrum server crash, how can I list my  transaction quickly?

And if electrum down, will I lost  all my bitcoin?

If the Electrum servers are all down (probably won't happen), you will see an old balance. You can set up an Electrum Personal Server just for you if something like that happens or you want to have better security.

Yes, the default server you use in Electrum will receive all your used addresses. Electrum will generate new addresses when addresses are used. The server won't know about them until it is asked, of course, and it can't predict your unused addresses.

Thanks! Do you mean that Electrum servers  are  decentralized ?  Is my transaction records hard to query if all Electrum servers crash?

And if all electrum down, will I lost all my bitcoin ?

Anyone can run an electrum server, similar to how anyone can run a bitcoin node. You can select which server to connect to. As long as you maintain a backup of your private keys, you should never lose your bitcoin, regardless of the availability of whichever wallet you use


text:
NXT clone paramiters
Hi am looking at creating a currency using NXT creation generator and have been looking for parts in the code to modify and test, this is more of a learning experience for myself.
Is there a way to change certain paramiters

Blocksize to increase it?
Block timing can this be increased either along side blocksize or separately?
Datacloud can this size be increased to upload larger files and also can it be changed so these are permenatly uploaded or put up and only removed when required by the person that uploaded them ?
Fees such as uploads, currency creation, asset creation can these be modified increase or decreased there base and max ?

I will probly have more questions, but I am looking were to find to modify these
appreciate the help!!

Of course there is a way to change anything. But you must carefully think over the changes you do. The source code is available here. Here are some directions:

Blocksize to increase it?

Change the MAX_NUMBER_OF_TRANSACTIONS constant

Block timing can this be increased either along side blocksize or separately?

It can be increased or decreased separately from the block size. In Nxt there is no constant for that. Easiest thing to do is to see how the BLOCK_TIME constant is used in Ardor and do the same in Nxt

Datacloud can this size be increased to upload larger files and also can it be changed so these are permenatly uploaded or put up and only removed when required by the person that uploaded them ?

The size can be changed - MAX_TAGGED_DATA_DATA_LENGTH. You cannot delete data which is already announced to the network. You simply cannot force someone to forget some data. If you find a way to do this, please tell me, we will solve the double spend problem in truly scalable way :)

Fees such as uploads, currency creation, asset creation can these be modified increase or decreased there base and max ?

They can. Search for the implementations of the nxt.Fee interface

Thanks for the feed back mate appreciate it , wish there was a way to direct message if there is im new here so not sure on it

Maybe slack - https://nxtplatform.org/slack/ ?

Thanks mate yes im on there ill see if I can connect there with you


text:
How to attach an encrypted message to a payment transaction inside a contract?
How can I attach an encrypted message to a payment transaction from inside a contract? In release 2.2.0e it was possible by just calling the SendMoneyCall API with .messageToEncrypt:
SendMoneyCall sendMoneyCall = SendMoneyCall.create(<chain id>)
        .recipient(<recipient account>)
        .amountNQT(<amount>)
        .messageToEncrypt("test message");

this doesn’t seem to work in version 2.2.1.
Do I have to do it manually now? Like first encrypting and compressing the message and then adding it to the transaction via sendMoneyCall.message(“test message”)?

Please post the answer as a self-answer, instead of as part of the question.

ok, sorry. I'm new here :)

I've asked this question in ardors slack developer channel and post it here for documentation. After a small dialog in which I detailed the occurring error with a small example contract I got an explanation with a working solution:
About the messageToEncrypt parameter, the problem is that when a transaction is submitted by a contract it is first generated without a secretPhrase then signed and broadcasted. This means that message cannot be encrypted when the transaction is generated.
Therefore to submit an encrypted message in your contract you need to encrypt it yourself using the technique in sample contract IgnisArdorRates line 94:
   // Encrypt the message
   EncryptedData encryptedData = context.getConfig().encryptTo(Account.getPublicKey(context.getSenderId()), Convert.toBytes(response.toJSONString(), true), true);

   // Send a message back to the user who requested the information
   SendMessageCall sendMessageCall = SendMessageCall.create(context.getChainOfTransaction().getId()).recipient(context.getSenderId()).
           encryptedMessageData(encryptedData.getData()).
           encryptedMessageNonce(encryptedData.getNonce()).
           encryptedMessageIsPrunable(true);
   return context.createTransaction(sendMessageCall);

I've adapted my example contract according to this answer and post it here to share the solution:
example contract:
package com.jelurida.ardor.contracts;

import nxt.account.Account;
import nxt.addons.AbstractContract;
import nxt.addons.JO;
import nxt.addons.TransactionContext;
import nxt.crypto.EncryptedData;
import nxt.http.callers.SendMoneyCall;
import nxt.http.responses.TransactionResponse;
import nxt.util.Convert;

public class TestContract extends AbstractContract {

    @Override
    public JO processTransaction(TransactionContext context) {
        TransactionResponse transaction = context.getTransaction();
        EncryptedData encryptedData = context.getConfig().encryptTo(Account.getPublicKey(context.getSenderId()), Convert.toBytes("test message", true), true);

        SendMoneyCall sendMoneyCall = SendMoneyCall.create(transaction.getChainId())
                .recipient(transaction.getSender())
                .amountNQT(transaction.getAmount())
                .encryptedMessageData(encryptedData.getData())
                .encryptedMessageNonce(encryptedData.getNonce())
                .encryptedMessageIsPrunable(true);

        return context.createTransaction(sendMoneyCall);
    }
}

unit test:
package com.jelurida.ardor.contracts;

import nxt.addons.JO;
import nxt.blockchain.Block;
import nxt.blockchain.ChildTransaction;
import nxt.blockchain.FxtTransaction;
import nxt.messaging.PrunableEncryptedMessageAppendix;
import nxt.util.Convert;
import org.junit.Assert;
import org.junit.Test;

import static nxt.blockchain.ChildChain.IGNIS;

public class TestContractTest extends AbstractContractTest {

    @Test
    public void encryptedMessageTest() {
        String contractName = ContractTestHelper.deployContract(TestContract.class);

        JO messageJson = new JO();
        messageJson.put("contract", contractName);
        String message = messageJson.toJSONString();
        ContractTestHelper.bobPaysContract(message, IGNIS);
        generateBlock();

        Block lastBlock = getLastBlock();
        boolean transactionFound = false;
        for (FxtTransaction transaction : lastBlock.getFxtTransactions()) {
            for (ChildTransaction childTransaction : transaction.getSortedChildTransactions()) {

                transactionFound = true;
                Assert.assertEquals("test message", extractMessage(childTransaction));

            }
        }
        Assert.assertTrue(transactionFound);
    }

    private String extractMessage(ChildTransaction transaction) {
        PrunableEncryptedMessageAppendix appendix = (PrunableEncryptedMessageAppendix) transaction.getAppendages().stream().filter(a -> a instanceof PrunableEncryptedMessageAppendix).findFirst().orElse(null);
        byte[] compressedData = appendix.getEncryptedData().decrypt(BOB.getSecretPhrase(), ALICE.getPublicKey());
        byte[] data = Convert.uncompress(compressedData);
        return Convert.toString(data, true);
    }

Hope it's helpful :).


text:
Is it possible to trigger a contract with a not prunable public trigger message?
In the current state pruning is not implemented. Therefore an attached public trigger message should stay in the blockchain until pruning is enabled. When this is the case, will it be possible to make the trigger message unprunable? This could be useful for contract params validation. For example:
If I trigger a contract with the following attached message: {"contract":"ExampleContract","params":{"veryImportantParameter":"42"}}
I would like to make this message public (so everybody can validate that I've triggered the contract ExampleContract with the parameter veryImportantParameter and it's value 42) and not prunable (so that everybody can validate the message at any time in the future).
Is this going to be possible?

Which blockchain?
What kind of contract? An ethereum contract? A bitcoin UTXO?
What do you mean by trigger message?

This question is related to the Ardor blockchain and its lightweight contract system.

I'm voting to close this question as off-topic because it is astroturfing. Many similar questions end up with implausibly detailed and fluffy responses from new users. It is not remotely related to Bitcoin.

This is a real question and I'm really interested in the answer. If I did something wrong, please tell me. I'll edit the question. All informations are just there to specify the question. I had really no intention to astroturf

There's multiple tags in this stackexchange site based on alternative cryptocurrencies and blockchain technology at large. Why is it an issue that this question is not related to Bitcoin itself?

Ardor has two levels of pruning. Pruning of messages (like the contract trigger message), data cloud items and shuffling artifacts are already implemented on each child chain. Child chain transaction pruning is scheduled for release later this year.
Only prunable trigger message are supported at the moment to reduce blockchain bloat.
Send your trigger message in plain text and setup an archival node to save it locally even after it is pruned. This will provide you unreputable proof that this message existed at the time when the contract was triggered and other nodes will be load this message automatically from your archival node at a later time.


text:
Problem making multisig PSBT on walletcreatefundedpsbt
I'm fighting with PSBT to do a 2: 2 multisig with bitcoin-cli on testnet. Those are the steps I follow:

Create a multisig with bitcoin-cli createmultisig 2 "["pubkey1", "pubkey2"]"

Create the psbt with createpsbt:
bitcoin-cli createpsbt '[{"txid": "578b667a5b2498bce06cf4b31e027a5a045af321f2465d3a7d8f302ac61759e6", "vout": 1 }, { "txid": "237bda433527d32ddce8da640e96efcbf3fddc1fbde8add362abe197cc3c151f", "vout": 0 }]' '{"data": "49879816ffbca992d07559d56c0cb8cbc14aa7eb896bc79f532d272595b5906f", "tb1q369frc2yk5vfly8ya57ed2qr7p3jef6fzaqyz6": 0.00009500 }'

On one signer, call to walletprocesspsbt: bitcoin-cli walletprocesspsbt $psbt

If I call here to analyzepsbt $psbt, this is what I get:

{
  "inputs": [
    {
      "has_utxo": true,
      "is_final": false,
      "next": "updater",
      "missing": {
        "redeemscript": "e6b13137de705c19718f1aaf6f80709a9e6c1a7c"
      }
    },
    {
      "has_utxo": true,
      "is_final": false,
      "next": "updater",
      "missing": {
        "redeemscript": "e6b13137de705c19718f1aaf6f80709a9e6c1a7c"
      }
    }
  ],
  "fee": 0.00000500,
  "next": "updater"
}

To add the redeemscript it says is missing, ¿can I use walletcreatefundedpsbt? I try this:
bitcoin-cli walletcreatefundedpsbt '[{"txid": "578b667a5b2498bce06cf4b31e027a5a045af321f2465d3a7d8f302ac61759e6", "vout": 1, "scriptPubKey": "a914e6b13137de705c19718f1aaf6f80709a9e6c1a7c87", "witnessScript": "5221021efcdb8d9afb724ae7c58a3886656b56e3311e26f80a1d88e5f1f49e04d30d4b210345beb99ed5fd6ecad0e4a26b797b604495ebf85630c34e126a83c110b76dffdd52ae","amount":0.00005000}, {"txid": "237bda433527d32ddce8da640e96efcbf3fddc1fbde8add362abe197cc3c151f", "vout": 0, "scriptPubKey": "a914e6b13137de705c19718f1aaf6f80709a9e6c1a7c87", "witnessScript": "5221021efcdb8d9afb724ae7c58a3886656b56e3311e26f80a1d88e5f1f49e04d30d4b210345beb99ed5fd6ecad0e4a26b797b604495ebf85630c34e126a83c110b76dffdd52ae","amount":0.00005000}]'  '[{"data": "49879816ffbca992d07559d56c0cb8cbc14aa7eb896bc79f532d272595b5906f"}, {"tb1q369frc2yk5vfly8ya57ed2qr7p3jef6fzaqyz6": 0.00009500 }']

but I get "Insufficient funds" (error -4) ¿What I' missing or put it wrong on walletcreatefundedpsbt command?
Thank you very much! :-D

Create a multisig with bitcoin-cli createmultisig 2 "["pubkey1", "pubkey2"]"

Here is your problem. createmultisig is a utility function that only computes the multisig address. It doesn't store or otherwise add that address to your wallet. As a result, when you invoke walletprocesspsbt to update/sign, the wallet has no idea what that address is, or how to sign for it.
You want to use addmultisigaddress instead.

To add the redeemscript it says is missing, can I use walletcreatefundedpsbt?

walletcreatefundedpsbt is an RPC to construct a PSBT from scratch; it's an alternative to the more manual createpsbt call, not a way to update an existing PSBT. You need to use walletprocesspsbt PSBT for that, but as I said, you first need to teach the wallet about the address you're using.

You mean we need invoke addmultisigaddress for both wallets? but error occurs: Only legacy wallets are supported by this command (code -4), how to fix it?

In descriptor wallets you need to use descriptors. For a 2-of-3 multisig that is multi(2,KEY1,KEY2,KEY3) where each KEY is an xpub, xprv, hex pubkey, or WIF key. You'll need to add a checksum, which can be computed using getdescriptorinfo.

Do you mean, In descriptor wallet, we cannot use addmultisigaddress or createmultisig to generate multisig address? Where i can find the article about it?

createmultisig still works, as it is just a utility for computing a multisig address which doesn't affect your wallet. addmultisigaddress indeed does not work for descriptor wallets, you need to use importdescriptors instead. See https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md

so we need importdescriptors of the multisig address into 3 wallets as watch-only address?

importdescriptors '[{"desc":"wsh(multi(2,028919e531c417c62d861d1ee76665c210cd6f41f4b08f1138c8a470a434fa1d3,02c066b88cd0eaca2dee364db02343e03d39393410825d008470b805377a6213c,02b88b98dcf19d89ef60ef2e8e4a612a846c6e346f85dc9d0dea66f5c64de2028))#cj03p9yd","timestamp":"now"}]' [   {     "success": false,     "error": {       "code": -4,       "message": "Cannot import descriptor without private keys to a wallet with private keys enabled"     }   } ]

You need a separate watch-only wallet to manage the multisig, see https://github.com/bitcoin/bitcoin/blob/master/doc/multisig-tutorial.md.

"Create a watch-only descriptor wallet (blank, private keys disabled). Now the multisig is created by importing the two descriptors: wsh(sortedmulti(,XPUB1/0/,XPUB2/0/,…,XPUBN/0/)) and wsh(sortedmulti(,XPUB1/1/,XPUB2/1/,…,XPUBN/1/)) (one descriptor w/ 0 for receiving addresses and another w/ 1 for change). Every participant does this", but how do i get the XPUB1~N?

You get those by calling listdescriptors on the individual signer wallets (as the document explains).

my "desc": "wpkh([f4b06474/84h/1h/0h]tpubDDRPyzHRPv3tMvtJ7qdTJkCh3e3xrUpctiyPUiKKD4MaJNRS1iMeaGsGAGDNd9wMcGHGExEVXxqH483dUwad9WN7YfPfFFwAU4hf5j5Vjrb/0/*)#hvuzw9t8", format is not m/84'/1'/0', why? it's in testnet.

thank you @Pieter Wuille, I am done my question, and found a issue here: https://github.com/bitcoin/bitcoin/issues/30177, have you ever met?

Here is your problem. createmultisig is a utility function that only
computes the multisig address. It doesn't store or otherwise add that
address to your wallet. As a result, when you invoke walletprocesspsbt
to update/sign, the wallet has no idea what that address is, or how to
sign for it.
You want to use addmultisigaddress instead.

I try with
bitcoin-cli addmultisigaddress 2 "[\"02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521\",\"035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349\"]"

{
  "address": "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr",
  "redeemScript": "522102861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d21652121035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c62934952ae",
  "descriptor": "wsh(multi(2,[ac6d6edb/0'/0'/2']02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521,[9e497453]035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349))#cpxsl54h"
}

I send some coins to this address. If I do:
bitcoin-cli listunspent 0 99999 [\"tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr\"]
[]

Empty. I need to importaddress to appear some UTXOs inside listunspent. I import address using this command:
bitcoin-cli importaddress "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr" "multisig" false

When you say "It doesn't store or otherwise add that address to your wallet". ¿If you see inside listunspent the UTXO associated with this address, I'm ok with PSBT to can fill the data it needs?
(have an update that fix the problem)
I create psbt with the command in my question, with importaddress I have the utxos associated with the multisig, I walletprocesspsbt with the first signer. This is what I get:
bitcoin-cli decodepsbt cHNidP8BAKYCAAAAAhXi9txucDKfTt7mXCZsKa0hsjgsLoq5YZGaUuwN6jbOAAAAAAD/////sB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0AAAAAAP////8CAAAAAAAAAAAiaiBJh5gW/7ypktB1WdVsDLjLwUqn64lrx59TLScllbWQb85KAAAAAAAAFgAUm/7/n/VJl/i0rBrmlSFsZ/NozEYAAAAAAAEAXgIAAAABsB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0BAAAAAP7///8B6iQAAAAAAAAiACBklOrolcGfaTYTyGvZL0jHx56tjndd0QiOUgFvu72yBZj+GwABASvqJAAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCID6mV3QiDUPp6EIweaenZx3kkHU1bro8nQn1PSmRt2ZFAiAxAlJ1OPtiw0lJNQ/VkbZOZ+s/onDRWC3nRAvAMvMorgEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAEApgIAAAACIfcY2yOhSRdNWwkluhcrdfnpZBjNkEzbBSjuZi9EY98BAAAAAP7////m9ElqxQQEla0RvsRKc4C1Pm0eWijkItpm0NWmwqFtLgEAAAAA/v///wIQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFNCYAAAAAAAAWABTmE28wyI0yfbWezbwt7AM5qC10qJj+GwABASsQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCIAcK7oIjvPK8bmtj/lYkERVWGArHkELHY3nm7SjpeK0XAiAjwUBJ5LNjjoY6ogXOYVHcsrIXhGtcQ35HL+qhK536iwEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAAiAgJgDXer7s2e/Bn+qUPtR+vziM9NkkvCozLNN/AZCCVd3xCsbW7bAAAAgAAAAIAEAACAAA==
{
  "tx": {
    "txid": "5fa020d46c8b64698b326d87635e212842889d2cca2bc23539b84321b6d90460",
    "hash": "5fa020d46c8b64698b326d87635e212842889d2cca2bc23539b84321b6d90460",
    "version": 2,
    "size": 166,
    "vsize": 166,
    "weight": 664,
    "locktime": 0,
    "vin": [
      {
        "txid": "ce36ea0dec529a9161b98a2e2c38b221ad296c265ce6de4e9f32706edcf6e215",
        "vout": 0,
        "scriptSig": {
          "asm": "",
          "hex": ""
        },
        "sequence": 4294967295
      },
      {
        "txid": "5d51933b9c291ab41dad0ef5ff0476707c2deee3f8f23aafdb7a452fd2281db0",
        "vout": 0,
        "scriptSig": {
          "asm": "",
          "hex": ""
        },
        "sequence": 4294967295
      }
    ],
    "vout": [
      {
        "value": 0.00000000,
        "n": 0,
        "scriptPubKey": {
          "asm": "OP_RETURN 49879816ffbca992d07559d56c0cb8cbc14aa7eb896bc79f532d272595b5906f",
          "hex": "6a2049879816ffbca992d07559d56c0cb8cbc14aa7eb896bc79f532d272595b5906f",
          "type": "nulldata"
        }
      },
      {
        "value": 0.00019150,
        "n": 1,
        "scriptPubKey": {
          "asm": "0 9bfeff9ff54997f8b4ac1ae695216c67f368cc46",
          "hex": "00149bfeff9ff54997f8b4ac1ae695216c67f368cc46",
          "reqSigs": 1,
          "type": "witness_v0_keyhash",
          "addresses": [
            "tb1qn0l0l8l4fxtl3d9vrtnf2gtvvlek3nzxtrctvx"
          ]
        }
      }
    ]
  },
  "unknown": {
  },
  "inputs": [
    {
      "witness_utxo": {
        "amount": 0.00009450,
        "scriptPubKey": {
          "asm": "0 6494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
          "hex": "00206494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
          "type": "witness_v0_scripthash",
          "address": "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr"
        }
      },
      "non_witness_utxo": {
        "txid": "ce36ea0dec529a9161b98a2e2c38b221ad296c265ce6de4e9f32706edcf6e215",
        "hash": "ce36ea0dec529a9161b98a2e2c38b221ad296c265ce6de4e9f32706edcf6e215",
        "version": 2,
        "size": 94,
        "vsize": 94,
        "weight": 376,
        "locktime": 1834648,
        "vin": [
          {
            "txid": "5d51933b9c291ab41dad0ef5ff0476707c2deee3f8f23aafdb7a452fd2281db0",
            "vout": 1,
            "scriptSig": {
              "asm": "",
              "hex": ""
            },
            "sequence": 4294967294
          }
        ],
        "vout": [
          {
            "value": 0.00009450,
            "n": 0,
            "scriptPubKey": {
              "asm": "0 6494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
              "hex": "00206494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
              "reqSigs": 1,
              "type": "witness_v0_scripthash",
              "addresses": [
                "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr"
              ]
            }
          }
        ]
      },
      "partial_signatures": {
        "02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521": "304402203ea65774220d43e9e8423079a7a7671de49075356eba3c9d09f53d2991b7664502203102527538fb62c34949350fd591b64e67eb3fa270d1582de7440bc032f328ae01"
      },
      "witness_script": {
        "asm": "2 02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521 035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349 2 OP_CHECKMULTISIG",
        "hex": "522102861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d21652121035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c62934952ae",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521",
          "master_fingerprint": "ac6d6edb",
          "path": "m/0'/0'/2'"
        },
        {
          "pubkey": "035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349",
          "master_fingerprint": "9e497453",
          "path": "m"
        }
      ]
    },
    {
      "witness_utxo": {
        "amount": 0.00010000,
        "scriptPubKey": {
          "asm": "0 6494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
          "hex": "00206494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
          "type": "witness_v0_scripthash",
          "address": "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr"
        }
      },
      "non_witness_utxo": {
        "txid": "5d51933b9c291ab41dad0ef5ff0476707c2deee3f8f23aafdb7a452fd2281db0",
        "hash": "5d51933b9c291ab41dad0ef5ff0476707c2deee3f8f23aafdb7a452fd2281db0",
        "version": 2,
        "size": 166,
        "vsize": 166,
        "weight": 664,
        "locktime": 1834648,
        "vin": [
          {
            "txid": "df63442f66ee2805db4c90cd1864e9f9752b17ba25095b4d1749a123db18f721",
            "vout": 1,
            "scriptSig": {
              "asm": "",
              "hex": ""
            },
            "sequence": 4294967294
          },
          {
            "txid": "2e6da1c2a6d5d066da22e4285a1e6d3eb580734ac4be11ad950404c56a49f4e6",
            "vout": 1,
            "scriptSig": {
              "asm": "",
              "hex": ""
            },
            "sequence": 4294967294
          }
        ],
        "vout": [
          {
            "value": 0.00010000,
            "n": 0,
            "scriptPubKey": {
              "asm": "0 6494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
              "hex": "00206494eae895c19f693613c86bd92f48c7c79ead8e775dd1088e52016fbbbdb205",
              "reqSigs": 1,
              "type": "witness_v0_scripthash",
              "addresses": [
                "tb1qvj2w46y4cx0kjdsnep4ajt6gclreatvwwawazzyw2gqklwaakgzs8l24zr"
              ]
            }
          },
          {
            "value": 0.00009780,
            "n": 1,
            "scriptPubKey": {
              "asm": "0 e6136f30c88d327db59ecdbc2dec0339a82d74a8",
              "hex": "0014e6136f30c88d327db59ecdbc2dec0339a82d74a8",
              "reqSigs": 1,
              "type": "witness_v0_keyhash",
              "addresses": [
                "tb1qucfk7vxg35e8mdv7ek7zmmqr8x5z6a9geyj9ae"
              ]
            }
          }
        ]
      },
      "partial_signatures": {
        "02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521": "30440220070aee8223bcf2bc6e6b63fe5624111556180ac79042c76379e6ed28e978ad17022023c14049e4b3638e863aa205ce6151dcb2b217846b5c437e472feaa12b9dfa8b01"
      },
      "witness_script": {
        "asm": "2 02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521 035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349 2 OP_CHECKMULTISIG",
        "hex": "522102861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d21652121035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c62934952ae",
        "type": "multisig"
      },
      "bip32_derivs": [
        {
          "pubkey": "02861fb3e2cb63816fa8019513cea0bd931d4c1530e3261b466ab9788d7d216521",
          "master_fingerprint": "ac6d6edb",
          "path": "m/0'/0'/2'"
        },
        {
          "pubkey": "035333ad355e76dddecce5514b9a999f4ec3002f9a00833b7b0fcfbc495c629349",
          "master_fingerprint": "9e497453",
          "path": "m"
        }
      ]
    }
  ],
  "outputs": [
    {
    },
    {
      "bip32_derivs": [
        {
          "pubkey": "02600d77abeecd9efc19fea943ed47ebf388cf4d924bc2a332cd37f01908255ddf",
          "master_fingerprint": "ac6d6edb",
          "path": "m/0'/0'/4'"
        }
      ]
    }
  ],
  "fee": 0.00000300
}

I sign with the second signer.
 bitcoin-cli --datadir=/home/biteskola/.daniel walletprocesspsbt cHNidP8BAKYCAAAAAhXi9txucDKfTt7mXCZsKa0hsjgsLoq5YZGaUuwN6jbOAAAAAAD/////sB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0AAAAAAP////8CAAAAAAAAAAAiaiBJh5gW/7ypktB1WdVsDLjLwUqn64lrx59TLScllbWQb85KAAAAAAAAFgAUm/7/n/VJl/i0rBrmlSFsZ/NozEYAAAAAAAEAXgIAAAABsB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0BAAAAAP7///8B6iQAAAAAAAAiACBklOrolcGfaTYTyGvZL0jHx56tjndd0QiOUgFvu72yBZj+GwABASvqJAAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCID6mV3QiDUPp6EIweaenZx3kkHU1bro8nQn1PSmRt2ZFAiAxAlJ1OPtiw0lJNQ/VkbZOZ+s/onDRWC3nRAvAMvMorgEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAEApgIAAAACIfcY2yOhSRdNWwkluhcrdfnpZBjNkEzbBSjuZi9EY98BAAAAAP7////m9ElqxQQEla0RvsRKc4C1Pm0eWijkItpm0NWmwqFtLgEAAAAA/v///wIQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFNCYAAAAAAAAWABTmE28wyI0yfbWezbwt7AM5qC10qJj+GwABASsQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCIAcK7oIjvPK8bmtj/lYkERVWGArHkELHY3nm7SjpeK0XAiAjwUBJ5LNjjoY6ogXOYVHcsrIXhGtcQ35HL+qhK536iwEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAAiAgJgDXer7s2e/Bn+qUPtR+vziM9NkkvCozLNN/AZCCVd3xCsbW7bAAAAgAAAAIAEAACAAA==
{
  "psbt": "cHNidP8BAKYCAAAAAhXi9txucDKfTt7mXCZsKa0hsjgsLoq5YZGaUuwN6jbOAAAAAAD/////sB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0AAAAAAP////8CAAAAAAAAAAAiaiBJh5gW/7ypktB1WdVsDLjLwUqn64lrx59TLScllbWQb85KAAAAAAAAFgAUm/7/n/VJl/i0rBrmlSFsZ/NozEYAAAAAAAEAXgIAAAABsB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0BAAAAAP7///8B6iQAAAAAAAAiACBklOrolcGfaTYTyGvZL0jHx56tjndd0QiOUgFvu72yBZj+GwABASvqJAAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFAQjaBABHMEQCID6mV3QiDUPp6EIweaenZx3kkHU1bro8nQn1PSmRt2ZFAiAxAlJ1OPtiw0lJNQ/VkbZOZ+s/onDRWC3nRAvAMvMorgFHMEQCIF3e8YzHPjqTKkdZcBkSr1e/h0wBUJCdw2m+PzjnQWR1AiAxmh4Skd48VE5ioCUQSr/GS3n5e3EqoD/AEJNv603tGgFHUiEChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSEhA1MzrTVedt3ezOVRS5qZn07DAC+aAIM7ew/PvElcYpNJUq4AAQCmAgAAAAIh9xjbI6FJF01bCSW6Fyt1+elkGM2QTNsFKO5mL0Rj3wEAAAAA/v///+b0SWrFBASVrRG+xEpzgLU+bR5aKOQi2mbQ1abCoW0uAQAAAAD+////AhAnAAAAAAAAIgAgZJTq6JXBn2k2E8hr2S9Ix8eerY53XdEIjlIBb7u9sgU0JgAAAAAAABYAFOYTbzDIjTJ9tZ7NvC3sAzmoLXSomP4bAAEBKxAnAAAAAAAAIgAgZJTq6JXBn2k2E8hr2S9Ix8eerY53XdEIjlIBb7u9sgUBCNoEAEcwRAIgBwrugiO88rxua2P+ViQRFVYYCseQQsdjeebtKOl4rRcCICPBQEnks2OOhjqiBc5hUdyysheEa1xDfkcv6qErnfqLAUcwRAIgPYTSLc5zz7sh2g6kKBhukRwGYIkWJGHRe8+3VYjTKswCIHhQKlV0qV5DXjuU9CqgXkulREaKKnDee8m+vu+xj7UFAUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSrgAAIgICYA13q+7NnvwZ/qlD7Ufr84jPTZJLwqMyzTfwGQglXd8QrG1u2wAAAIAAAACABAAAgAA=",
  "complete": true
}

but now the signatures are missing:
bitcoin-cli analyzepsbt cHNidP8BAKYCAAAAAhXi9txucDKfTt7mXCZsKa0hsjgsLoq5YZGaUuwN6jbOAAAAAAD/////sB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0AAAAAAP////8CAAAAAAAAAAAiaiBJh5gW/7ypktB1WdVsDLjLwUqn64lrx59TLScllbWQb85KAAAAAAAAFgAUm/7/n/VJl/i0rBrmlSFsZ/NozEYAAAAAAAEAXgIAAAABsB0o0i9FetuvOvL44+4tfHB2BP/1Dq0dtBopnDuTUV0BAAAAAP7///8B6iQAAAAAAAAiACBklOrolcGfaTYTyGvZL0jHx56tjndd0QiOUgFvu72yBZj+GwABASvqJAAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCID6mV3QiDUPp6EIweaenZx3kkHU1bro8nQn1PSmRt2ZFAiAxAlJ1OPtiw0lJNQ/VkbZOZ+s/onDRWC3nRAvAMvMorgEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAEApgIAAAACIfcY2yOhSRdNWwkluhcrdfnpZBjNkEzbBSjuZi9EY98BAAAAAP7////m9ElqxQQEla0RvsRKc4C1Pm0eWijkItpm0NWmwqFtLgEAAAAA/v///wIQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFNCYAAAAAAAAWABTmE28wyI0yfbWezbwt7AM5qC10qJj+GwABASsQJwAAAAAAACIAIGSU6uiVwZ9pNhPIa9kvSMfHnq2Od13RCI5SAW+7vbIFIgIChh+z4stjgW+oAZUTzqC9kx1MFTDjJhtGarl4jX0hZSFHMEQCIAcK7oIjvPK8bmtj/lYkERVWGArHkELHY3nm7SjpeK0XAiAjwUBJ5LNjjoY6ogXOYVHcsrIXhGtcQ35HL+qhK536iwEBBUdSIQKGH7Piy2OBb6gBlRPOoL2THUwVMOMmG0ZquXiNfSFlISEDUzOtNV523d7M5VFLmpmfTsMAL5oAgzt7D8+8SVxik0lSriIGAoYfs+LLY4FvqAGVE86gvZMdTBUw4yYbRmq5eI19IWUhEKxtbtsAAACAAAAAgAIAAIAiBgNTM601Xnbd3szlUUuamZ9OwwAvmgCDO3sPz7xJXGKTSQSeSXRTAAAiAgJgDXer7s2e/Bn+qUPtR+vziM9NkkvCozLNN/AZCCVd3xCsbW7bAAAAgAAAAIAEAACAAA==
{
  "inputs": [
    {
      "has_utxo": true,
      "is_final": false,
      "next": "signer",
      "missing": {
        "signatures": [
          "9e497453046a2170505985012c40e447b24a0c9a"
        ]
      }
    },
    {
      "has_utxo": true,
      "is_final": false,
      "next": "signer",
      "missing": {
        "signatures": [
          "9e497453046a2170505985012c40e447b24a0c9a"
        ]
      }
    }
  ],
  "estimated_vsize": 276,
  "estimated_feerate": 0.00001086,
  "fee": 0.00000300,
  "next": "signer"
}

I thought that using walletprocesspsbt among other things it signed the UTXOS.
Thank you very much! :-D
UPDATE1:
The signature missing was fixed combining both signatures:
bitcoin-cli combinepsbt '["signer1_psbt","signer2_psbt" ]'

https://blockstream.info/testnet/tx/5fa020d46c8b64698b326d87635e212842889d2cca2bc23539b84321b6d90460?expand
As I understand, one signer can createpsbt and walletprocesspsbt. The other signer make the same and then combine both psbt ¿right?


text:
Connection Refused
I am running bitcoind in unbuntu 16.04. And a web server running in docker container. When I excuted curl in container bash
curl --user user:pass --data-binary '{"jsonrpc":"1.0","method":"getblockchaininfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:18332/

response is curl: (7) Failed to connect to 127.0.0.1 port 18332: Connection refused
docker inner address 172.17.0.1
. However, curl in command line directly is ok.
Below is .conf setting:

server=1
testnet=1
rpcuser=user
rpcpassword=pass
rpcallowip=172.17.0.1
rpcport=18332
rpcconnect=127.0.0.1

I have tried all possible combinations of ip address and port number. All the results are 'Connection refused'
Can anyone advise me how to resolve the problem?
Thanks
Regards, Max

Since Bitcoin Core 0.17 certain config file options are net-specific. In particular this is true for rpcport.
This means you need to write it as test.rpcport=18332 now.
More information can be found in the 0.17 release notes: https://bitcoincore.org/en/releases/0.17.0/ (look for "Configuration sections for testnet and regtest").

Thank you for your help. But I don't think it is the reason why I can't connect bitcoind daemon from docker.

in the versions 0.15+ bitcoind rpc require rpcauth in the bitcoin.conf file.
rpcauth = user: password //generated with python script


text:
What is the cheapest way to pull the data from bitcoind/bitcoin-core?
I am wondering if there is a cheap way to scrape the bitcoind data. I am using a remote server and cannot spend too much time running this program otherwise it would be expensive. I am wondering if there is a way to speed up the RPC scraping (meaning a setting like dbache which could DRASTICALLY speed things up) which I wrote a python script or another way to do this. Any thoughts?

Do you want to parse the blockchain yourself? Just parse blk*.dat files

I know that is possible, I was wondering if you have any suggestions on that. It would take long to do this. Also how would you scrape the value of the inputs since you have to reference a previous transaction? I have not found much documentation on this.@amaclin


text:
How to send payment through a predefined route?
Attempting a payment through a predefined route using:
lncli -network=testnet queryroutes 02e34c1b4c5f8e7419cf4d10e3bc9651d46dc1af68df6a7b81a24951a9192aa9c4 25000 | lncli -network=testnet sendtoroute -pay_hash=45b9255c8648c6c1f60e394e555f745af31ed7fab385d0cf9e82b62ce8e8dfba -

Always give me back:
{
    "payment_error": "FinalExpiryTooSoon",
    "payment_preimage": "",
    "payment_route": null
}

Regardless the expiry I set in the addinvoice command.
Can someone clarify Why?
Moreover, how is it possible to use the sendtoroute command using the routes.json obtained before from the queryroutes command?

Could you try adding “--final_cltv_delta=144” option to your queryroutes command?

Adding this option works!

Glad it helped. Added an explanation of why you need this and posted it as an answer.

TL;DR. You need to specify --final_cltv_delta=144 option in the lncli queryroutes command.
Longer answer... When payment is routed through Lightning Network, each intermediate node has a potential ability to steal the funds being transferred. To prevent this from happening, intermediate nodes cannot move the money immediately, but only after a certain period of time. And within this period the funds can be claimed back by a legitimate owner.
final_cltv_delta option specifies this period of time (measured in the number of blocks) for the last node in the chain of hops. When you query routes, the default value is small (I believe it was 9 at some point). But this value is not accepted by most lnd nodes, which require a longer period of 144 by default.


text:
library for light-weight wallet : btcsuite or BitcoinJ
Do btcsuite + Neutrino(Lightning-lab) together provide sufficient foundation for light client capable to service onchain transactions (not multisig & not related to Payment Channels)?
Or is it possible to use Neutrino in conjunction with BitcoinJ to replace its Bloom filters?
The app will focus on bitcoin onchain transactions, but in future we'd like to do Lightning transactions also.


text:
Why is the obscured commitment number necessary in lightning commitment TX's?
The obscured commitment number for each commitment transaction is the lower 48 bits of:
SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)

It is encoded in the lock time and sequence fields (24bits each) of the commitment transaction. I don't understand why it is necessary, the BOLT rfc reads:

This obscures the number of commitments made on the channel in the
  case of unilateral close, yet still provides a useful index for both
  nodes (who know the payment_basepoints) to quickly find a revoked
  commitment transaction.

Why doesn't the TXID of the commitment TX suffice as lookup index key?

Looking at the c-lightning code I find this call:
    txs[0] = commit_tx(ctx, &channel->funding_txid,
               channel->funding_txout,
               channel->funding_msat / 1000,
               channel->funder,
               channel->config[!side].to_self_delay,
               &keyset,
               channel->view[side].feerate_per_kw,
               channel->config[side].dust_limit_satoshis,
               channel->view[side].owed_msat[side],
               channel->view[side].owed_msat[!side],
               committed,
               htlcmap,
               commitment_number ^ channel->commitment_number_obscurer,
               side);

in particular the following line:
commitment_number ^ channel->commitment_number_obscurer

Tracing down the commitment_number variable this suggests to me that it is really an integer. If you see how often in the code it has to validated that two commitment transactions are directly succeeding each other it makes sense to have an unobscured integer instead of a txid. Consider For example this code block:
    /* FIXME: Document this requirement in BOLT 2! */
    /* We can't send two commits in a row. */
    if (peer->revocations_received != peer->next_index[REMOTE] - 1) {
        assert(peer->revocations_received
               == peer->next_index[REMOTE] - 2);
        peer->commit_timer_attempts++;

It is obscured later since the information how many commitment tx existed should not be public. It is as far as I understand obscured with an OTP via XOR. The OTP is the one you mentioned above. The idea is to have an integer that can be used but obscure it when being sent to the blockchain. I did not find a position in the code where the obscured value is taken and processed to a clean value however.
I hope that helps (:

Thx for the code lookup Rene. The obscured commitment number is encoded in the commitment transaction for the node, so that during a unilateral close it can quickly lookup which state was broadcast by the counterparty (my understanding), and respond accordingly. Why cant the txid be used as a lookup key (txid->commitment nr)?

for the reasons that I have mentioned it seems more convenient to have an index number for the commitment transactions in memory. If you know it is Commitment Transaction number 100 you can probably derive the revocation key / redeem script via the key derivation instead of storing all that state for every txid.

I don't mean in-memory, but rather why these 48bits help to facilitate a lookup during channel close. I presume a single key represents a lookup key in persistent store to fetch data(sigs) that are required to respond to a revoked close of that state. If this hash-map key were just the unobscured integer, as you suggest, how could this integer be efficiently inferred from the obscured commitment number? (hash-digest). It must be an efficient way for a peer to immediately infer the broadcast state.

For the store lookup (in the implementation), it would make more sense to index by obscured commitment number than state integer as that is what is broadcast. I am open to being mistaken, but I suspect it has something to do with 48bits (obscured key) vs 256bits(TXID)?


text:
Why can’t lightning tx’s be signed with sighash single to allow for fee updates?
Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?
If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed...

Hmm... I realize it wouldn't be possible to single sign multiple in/output pairs, which all share the same multisig input, given that the indices between input and output would differ with all pairs except for one.

The question was originally referring to unilateral channel closes, I could have made that clearer.
Sighash single does not work since it can only sign in/outs at the same index.
An idea proposed by lightning developers has been to add output hooks (spendable by each counter-party) with no/low amounts which are spendable by child transactions which lift the fee-rate of the entire tx chain (CPFP).
This has the problem that a long (malicious) low fee-rate chain can max out the descendent limit and anchor the parent at the bottom of the mempool, thereby preventing any CPFP by the counterparty (This proposal would have 2 hooks per commitment transaction).
The solution for this is the mempool carveout in core (merged in July 2019), which applies when the (user-configurable) descendent limit has been reached. A single child can still be accepted to the tx package in this case, which is used by the non-malicious party to increase feerate of the tx package.

Let's distinguish a couple cases:
Cooperative close
In the case of a cooperative close, the two channel partner can agree on any transaction they want. Thus, they can pick the fee rate on the spot. As the two outputs would likely not have any timelocks, either party could use child-pays-for-parent (CPFP) to bump the initial closing transaction. They could even issue an RBF transaction initially and update it later if it doesn't confirm quickly enough.
Unilateral close
The party that initiates the closing transaction has their funds locked to allow the counterparty to apply their breach-remedy if an old state was published. This means that traditionally only the counterparty can make use of CPFP to accelerate the closing transaction. This is inconvenient, because there wouldn't be a need for a unilateral close unless the counterparty were currently uncooperative.
The recent lnd 0.7.0 release notes mention that improvements were made to their transaction closing procedures to support both RBF and CPFP.

Thank you @Murch. Since I asked the question, my understanding has evolved a little. Firstly, output hooks for both parties can be added to commitment tx's so that CPFP can be applied during unilateral closing by any party. This has the problem that a long low fee-rate chain can max out the descendent limit and anchor the parent at bottom of mempool, and preventing any CPFP by counterparty. The solution for this is the mempool carveout in core (https://github.com/bitcoin/bitcoin/pull/15681), which allows for an additional child TX even if the descendent limit has been reached.

Are out-of-band fee payments to confirm a lightning closing transaction the only way to manage a situation where the sat/kw of a previously signed commitment tx are simply below market?

Yes, you will have to do it out-of-band, as you would not be able to use fee rate that is higher than the last signed commitment transaction within the framework of the Lightning Network protocol. BOLT #2 states that when the funder sends a closing_signed message, the fee_satoshi parameter should be less than or equal to the base fee of the final commitment transaction. The receiver should fail the connection if it doesn't meet this criteria.
However, the above rules can be circumvented. The first workaround was explained by @Murch through CPFP and RBF. The second one can be done within the Lightning Network protocol framework. The funder can send a update_fee message (before the shutdown message) updating its fee rate to a higher one. The funder must however, afford the new fee rate on the receiving node's current commitment transaction or the peer receiving the message will fail the channel. It can then send a dummy transaction (say 1 satoshi) across that channel to its peer. Now, send a closing_signed message with the same fee_satoshi as the last updated fee and your transaction can go through within the bounds of the Lightning Network protocol because it was this fee that was used for the last commitment transaction.

If additional inputs/outputs could be added, fees could be easily adjusted to the fee rate during channel closing and not at the time when the tx was signed

It would be a double edged sword and could create the issue of transaction confirmation. Say one party signs with SIGHASH_SINGLE, and then waits for the other party to sign and broadcast the transaction. The other party can then add multiple addresses to which it wants the payout. Due to these added outputs, the feerate_per_kw will be lower than what the counterparty agreed to at the time of open_channel message and hence the time that can take to confirm this transaction will be higher than what the counterparty node expected. This can further be used for DoS attacks, where I open channel with participants, but then add as many outputs such that the fee rate dips below that miners would consider in including it in the block, thus locking nodes out of their funds.

Thanks Ugam Kamat. My understanding has improved on this since asking this question 7 months ago. Sure, the feerate can be updated collaboratively. I am interested in the unilateral close case. Please consider my comment (mempool carve-out) to the answer above regarding the anchoring of the commitment transaction to the bottom of mempool via low-fee-rate children.


text:
BTC full node very slow block downloads
I have a server with 32 Gigs of ram and running the node on a docker container using Bitcoin Core Daemon version v0.15  with 8333 ports mapped
Nodes been running for 2.5 weeks still 300k blocks and most of the time connectioncount is 0, only once I saw it jumped up to 60
I even increased the dhcache
why is it taking so long ? How do I speed things up ? for most of the guys it took only 1-2 weeks

Update
01- This is my setup

02- It was working fine and when I checked weather ports are open from outside network before 300k sync
I - https://www.yougetsignal.com/tools/open-ports/
Two weeks before 8333 OPEN
Now 8333 OPEN
II - https://bitnodes.earn.com/#join-the-network
Two weeks before 8333 OPEN and Reachable
NOW unreachable
III- Connection speed 10 MB

would you happen to know the bandwidth limits of your node's ISP?

Don't forget that you are downloading 150GB From different nodes. It took four days with me with a good internet connection and 16GB ram. If your donwload speed 33mb per second, it will takes 82,5 hour if all nodes upload speed 33mb per second.

It would be useful for considering what the issue may be if you could please edit your question to explain more about your network configuration, how connections are routed to the public internet, your connection speed and type and, any other useful information.

Additionally, details of your Bitcoin Core configuration may be useful, what parameters you use on the command line and your bitcoin.conf file.

I did not do any changes to my conf file

Your node should try and make 8 outbound connections to other nodes first. Forwarding port 8333 is just to allow incoming connections and is not required for your node to sync up.
So, thinking first of connectivity you should work through the basics:
Restart your modem and router equipment. Shut down bitcoind with >bitcoin-cli stop. Reboot your Ubuntu host and reboot your Docker session, restart bitcoind.
Can you resolve DNS queries from your Docker session, can you make successful HTTP requests from your Docker session (curl down some file or wget)? Can you >nmap seed.btc.petertodd.org -p 8333 which doesn't always work first try, it is a DNS round robin - just try several times is enough you should get at least one success.
After network connectivity is resolved, you may wish to check out this answer for some more information.

Hey thanks for all the suggestions and advice, I turned off the firewall for now. I have enabled port forwarding yet some how still my btc traffic is filtered found out that with this command "nmap seed.btc.petertodd.org -p 8333" provided by @willtech, Any way found the issue its the firewall I am going to look into it in more detail

You won't be able to sync without having any connections. The problem is that you have 0 connections; make sure that you don't have any firewalls (either in your docker container, the host, your router, or your ISP) that is blocking Bitcoin traffic.

It was running very slowly its 3 weeks and I have 300k blocks but suddenly everything stopped, as I described in my update port 8333 is still open and accessible deom 3rd party port checkers but not accessible from bitnodes checker

Again, make sure that there is not anything blocking the connection. Even if it was working a few weeks ago, your ISP could have changed something that blocked it. Or an update to your OS or other software may change your computer's firewall.

I checked everything ISP - Not blocked , Ubuntu Iptables - Not Blocked, Docker Container - Not Blocked
can anyone tell me the steps to diagnose this issue ?  or its useless running this full node Im going to quit

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Automatically close the bitcoin-qt when enable SSL for RPC
I Just try to enable SSL for bitcoin-qt RPC call. I follow the SSL on RPC
link to archive my target. But I am getting the following error and close the bitcoin-qt automatically.

I am using the bitcoin-qt 0.16.3

Support for SSL protected RPC was removed in Bitcoin Core version 0.12.0 (released in february 2016).
See https://bitcoin.org/en/release/v0.12.0#rpc-low-level-api-changes for the release notes on this, and also a workaround.

Thanks for answering. I don't understand why Bitcoin core developer is remove the SSL supported RPC on new versions...?? Actually it is decrease the security..??

Generally the RPC interface is intended for locally running services that you trust. It isn't designed to be exposed over the internet. If you have a need for that, it's probably better to develop a wrapper with protections in yourself (for example, not exposing dumpprivkey or importmulti or even `stop).

But actually I need to run it remotely. Any way are available to enable SSL for RPC call for bitcoind...???

Using of Bitcoind version 0.11 is a solution for my problem ..???

@salman farris The release notes I linked to explain how it can be done using stunnel or apache. Please, do not use 0.11. It is no longer maintained and has several critical issues.

Can you  please share the link for applying ssl using stunnel or apache for rpc of bitcoind...??

The link is in my answer.

Please answer my another question as possible. The link is https://bitcoin.stackexchange.com/questions/85816/create-a-multi-user-web-wallet-using-bitcoind-rpc-call


text:
Words to seed translation
In bitcoin wallet that support bip39 mnemonic code, is there a way to get the 12/24 words from the seed generated by them?
Or the translation is one-way only (from words to seed)?

There is no way to convert the resulting seed back to the original mnemonic.
As stated in the BIP 39 proposal:

To create a binary seed from the mnemonic, we use the PBKDF2 function
  with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
  string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.

The seed (and optional passphrase) are passed through pbkdf2, which is not reversible.


text:
How convert a mnemonic phrase back and forth between different number of words?
I'm relatively new to cryptocurrencies in general and I've tried using Bitcoin and a few altcoins, but it always bothers me that some digital assets are not available in all wallets. To my understanding, I could use the same mnemonic phrase in all wallets, even if some assets are not listed, if that's true I wouldn't have to store a different list of words for each wallet. The only problem is that most popular wallets support a different numbers of words in the mnemonic phrase. Is it possible to convert back and forth between say, for instance, a 24-word phrase to a 12-word phrase, and what tools can I use to make the conversion?

You'll find the technical details how those words map to a key in the BIP39 spec. It's in theory possible that there are two sentences that generate the same key but being able to find such a (HMAC-SHA512) collision would be a huge issue for cryptography in general (https://crypto.stackexchange.com/questions/3049/are-there-any-known-collisions-for-the-sha-1-2-family-of-hash-functions) Though you might earn something similar to a nobel price if you find a way :)

Is it possible to convert back and forth between say, for instance, a 24-word phrase to a 12-word phrase, and what tools can I use to make the conversion?

No, that is not possible. The mnemonic words represent an entropy, for example the 24 word mnemonic phrase represents 256 bits of entropy while a 12 word mnemonic represents 128 bits of entropy. These mnemonic words are passed to a PBKDF2 function to generate a seed that will then be used to generate master keys for different tokens. It's also important to note that if you use a passphrase to your wallet, that passphrase will be used as a 'salt' in the PBKDF2 function and will generate a completely different seed, had you not used a passphrase.

To my understanding, I could use the same mnemonic phrase in all wallets, even if some assets are not listed, if that's true I wouldn't have to store a different list of words for each wallet

Care has to be while doing that as many wallets use different paths of master key generation. If you use multiple wallets interchangeably, try to note the derivation path. For example, say hardware wallet A uses m/49'/0'/0' as the path, it will generate completely different addresses as compared to a wallet that will use a m/44'/0'/0' derivation.

I've asked myself similar questions which lead to learning more about mnemonics
with Bitcoin, and like many other (not all) cryptocurrencies, which use BIP39 which is a specification based on a unique wordlist of 2048 words (zero-indexed from 0-2047) available in various languages (although I should note that you cannot translate words across supported languages as they don't hold the same index values across languages for a given mnemonic, in terms of one "conversion" method you might be implying).

The purpose of BIP39 is to create a mnemonic that is human-readable
(easy to write, recite, read, etc..) compared to the underlying
binary data that the mnemonic represents which is machine-readable
(zeroes and ones, which can be represented in hex format or other
notation/base numbers) but is not easy to write/recite and thus BIP39
solves that problem, however, understanding what is happening
underneath the surface is key for dealing with mnemonics and taking
control of your crypto security.

About mnemonics: Underlying every mnemonic is a very large random number and a checksum that gets added to the end, which is why you cannot just choose your own 12 or 24 words, as a portion of the last word is computed based on this checksum (more on that below).
For example, in BIP39 the wordlist corresponds to the range of 2^11 power (i.e. 2048) and the reason why the mnemonic ends up being 12 or 24 words depends on the desired security in terms of bits, depending on whether it is 128 bits or 256 bits.
So when you click to create a BIP39-compliant wallet there should be a cryptographically-secure pseudo-random number generator (CSPRNG) such as the WorldWideWide Consortium (W3C) Cryptography API for web-based wallets (note: I am a contributor to that spec on Github) running locally that gathers various bits of randomness from your local device in a way that would make it difficult for an attacker to replicate or predict, and then those bits are used as the initial entropy (to create the mnemonic).

In other words, for a 24-word mnemonic, the device would produce 256
bits and would convert that string to a byte array and hash it using
SHA256, which results in another 256-bit output of which the leading
8 bits are taken and appended to the end of the initial entropy
making it 264-bits long.
If you divide 264 bits by 11-bits per word, the resulting 24 groups
of 11-bits each correspond to the same 11-bit index value of where
each word is on the list (where 0 = 00000000000 and 2047 =
11111111111). So with each word corresponding to an 11-bit number in
the resulting mnemonic. The words are just an easy way to find the
11-bit number, to recreate the initial entropy+checksum to derive the
wallet.

In terms of converting:
It is not recommended to choose your own words, firstly because that selection process could have some bias that would reduce the resulting security of the mnemonic compared to a randomly generated one, and secondly because the checksum must be computed deterministically (so if you cut your 24-words in half and used the first 12 in another wallet, there is a very low chance it would be checksum-compliant (1/16 chance), whereas choosing your own 24-words would be even more unlikely to be checksum complaint (1/256 chance).

Therefore, it is best not to choose your own words or slice your
mnemonic, but rather use trusted software in a cold-storage
environment (offline) for maximum security.

Entropy: The same applies for choosing your own entropy, in terms of it being best to leave it to trusted software. Although, others in the industry have given some examples of flipping a coin 128 times and writing a 1 for every heads and 0 for every tails, which is a way to manually create 128-bits of entropy for a wallet (where the wallet would compute the 4-bit checksum) provided the coin flip process is random (i.e. no one-side weighted coin).

However, many wallets don't allow you to paste entropy, and only
allow a mnemonic to be imported or to be generated on the fly.

There is a mnemonic converter tool (note: I am a contributor to it on Github) with advanced features that can accept entropy to create a mnemonic of various lengths but I wouldn't suggest this for someone that just started or even for those with years of experience unless you are fluent with the BIP39 specification, as well as BIP44 and BIP32, and all the countless ways that one tiny mistake can lead to an irreversible loss of funds.
Regarding the question of converting: While I am not sure exactly what you meant by "converting" assuming that you meant slicing a 24 mnemonic in half to use just the first 12 words, I have explained above why that isn't a viable option, unless the 12 words end up being checksum-compliant. (some software can scan through valid 24-word mnemonics to find one that is also checksum-complaint when using only the first 12-words, but the last 12 words would likely not be checksum-compliant as there would be a 1/256 chance for both the first 12 AND last 12 to be).

Such mnemonics exist but are hard to find/create while maintaining
the desired level of security in terms of bits (reducing a mnemonic
by one word reduces its security by half, thus a 12-word mnemonic
doesn't have half the security of a 24-word mnemonic but instead has
security equal to just the square root of a 24-word mnemonic, where
2^128*2^128 == 2^256. Note: I have written a similar program that
finds valid reversible palindromic mnemonics that are checksum
compliant in terms of BIP39, but only for education purposes.

Regarding using same mnemonic in all wallets: If a wallet is compatible with BIP39, there is a good chance it is also compatible with BIP44 to support multiple-account/coins which means that so long as the correct derivation path has been added to support by the developers of that wallet, that cryptocurrency will be supported and can be used with your existing mnemonic (but not if they use a different wordlist, like Monero, for example, which is not BIP39 compatible). This is why I like to think of mnemonics as crypto vaults, not wallets (as one mnemonic can contain multiple cryptocurrencies accounts that each contains multiple wallets, see HD wallets to learn more about that based on BIP32).

While having all your crypto assets consolidated on one mnemonic
could be convenient, it also concentrates the risk in terms of the
custody responsible to manage that mnemonic, whereas, having multiple
mnemonics with multiple cryptocurrencies across each adds the burden
of more crypto vaults to manage but reduces the risk in case one is
compromised (I would argue most savvy crypto investors have multiple,
as one or more could be used for hot-wallets that are on
internet-connected devices, whereas, other mnemonics used for
cold-storage are on hardware wallets or devices that never connect
online.

Takeaway: it is best to use the software provided by the underlying token/cryptocurrency project as some projects use a different wordlist, and/or other differences that could render the mnemonic incompatible and lead to a permanent loss of funds, or other inconveniences such as if the same mnemonic could derive different addresses that don't match across software even with the same derivation path chosen if the root seed or other steps diverge for unknown reasons (and such troubleshooting is very technical to find a potential bug).
Example technical data for a randomly-generated mnemonic (don't use this with real funds):
Initial entropy of 128 bits in hex format:
659b8a03bfbb80cdcdc3c383d4b0d505
Entropy as bytes:
bytearray(b'e\x9b\x8a\x03\xbf\xbb\x80\xcd\xcd\xc3\xc3\x83\xd4\xb0\xd5\x05')
SHA-256 hash digest of entropy bytes, in hex format:
c993b627272ef0cbc683ce275cf47ff82f73403ece8155bdd92c2dca2d86e3b1
Partial fragment of initial "byte" of hash representing first 4 bits:
c
First n bits of hash to convert to hex:
c
Checksum (hex to bits):
1100
Initial entropy + checksum = total bits:
011001011001101110001010000000111011111110111011100000001100110111001101110000111100001110000011110101001011000011010101000001011100
Length of total bits:
132
Divided into 12 groups of 11 bits:
['01100101100', '11011100010', '10000000111', '01111111011', '10111000000', '01100110111', '00110111000', '01111000011', '10000011110', '10100101100', '00110101010', '00001011100']
Corresponding index values for each group (in base 10):
[812, 1762, 1031, 1019, 1472, 823, 440, 963, 1054, 1324, 426, 92]
Corresponding mnemonic:
grain sword liberty legal retreat group damage journey long pitch crystal argue

I wanted to have a converter that I could use to have access to the same assets in two different wallets with different mnemonic phrase word count so that I cold just store either the 12-word phrase or the 24-word phrase and use it to restore either wallet with the same HD account. But it seems it's not posible from what you said.

Right, it is not possible as there are no collission, as there are only 2048^12 possible 12 word mnemonics of which only 2^128 are valid due to the checksum requirement (and 2048^24 possible 24-word ones with only 2^256 that have valid checksum), and every single one of these theoretically-possible mnemonics including the invalid ones each have a distinct underlying entropy and there is no direct relation from one mnemonic to another, as changing just one bit will have a waterfall effect and change all the words.


text:
How can I make transaction output time locked?
Is it possible to submit some coins to some address and make them spendable after some period of time?
Like I want submit 1btc to address 1Kc24m... and make that output to be spendable after january 1st 2030.

Yes, you can use OP_CHECKLOCKTIMEVERIFY opcode in the locking script of the output. This opcode takes either blocks or Unix Epoch Time (seconds since 1-Jan-1970) as the parameter to lock. If the parameter is non-zero and below 500 million, it is interpreted as a block height, if it is greater than or equal to 500 million, it is interpreted as a Unix Epoch timestamp. When you would reference this UTXO at the time of spending, you need to set the transaction nLocktime equal to or great than the OP_CHECKLOCKTIMEVERIFY. The nLocktime parameter while spending should be same as what was specified in the CLTV; i.e. if the CLTV locking parameter was in blocks, it should be specified in blocks, otherwise in Unix Epoch timestamp.
Since you want it to be spendable after 1st Jan 2030, that is equivalent to timestamp of 1,893,456,000 (or 0x70dbd880). So your locking script will be concatenation of:
OP_DATA (size of CLTV_expiry): 0x04
CLTV (little endian): 0x80d8db70
OP_CLTV: 0xb1
OP_DROP: 0x75
OP_DUP: 0x76
OP_HASH160: 0xa9
OP_DATA (size of address): 0x14
Address: <address>
OP_EQUALVERIFY: 0x88
OP_CHECKSIG: 0xac

Two things to note: (1) When you are spending this transaction, the input referencing this UTXO needs to have nSequence value between 0xF0000000 to 0xFFFFFFFE. (2) Median_time (time of last 11 blocks) is used to check nLocktime when the script is evaluated which is generally about hour behind the actual time on your wall clock.

How can one build such a transaction, though, except with a binary/hex editor, "manually"?

@Gabriel you can try this link which has multiple examples and code samples https://bcoin.io/guides/cltv.html

Can the nSequence field be any value as long as it's not 0xffffffff?


text:
How can I benefit by running a full Bitcoin node?
I noticed that I can run a node with Bitcoin Core.
If I open my computer always and make the full node run on my device, what benefits can I get? Is there any reward for serving this?

No, full node operators are not compensated in any way. If you run a full node, you will receive no monetary benefit.
However running a full node does benefit you. It means that you are contributing to the network's security. Your full node is verifying and relaying valid blocks and transactions so you are contributing to the transmission of blocks and transactions and ensuring their validity. This then corresponds to your node contributing to the health of the network and helping the network stay alive.
Furthermore, a full node allows you to have privacy and security in your transactions. Because a full node fully verifies every block and transaction, when you use it as a wallet (or have a wallet that is connected to it), your transactions are guaranteed to be valid and there is almost no possibility that you can be defrauded (assuming that your node is well connected). It also gives you more privacy as there is not one server or node that is giving you data as with SPV wallets.

Thanks very much for the information. Just one more question, what is "SPV" referring to in the last sentence?