Does the nodes of the network check that the signature is from the private key of the sender, by checking if it can unlock his public key provided in the transaction ? Yes. Every node receiving a transaction on the network verifies it before broadcasting it (verifying includes verifying its encoding, its signature(s) validity, etc..). |
|
|
|
Hi, ECDSA stands for Elliptic Curve Digital Signature Algorithm and is therefore an algorithm used to create a signature from a message (here the transaction). Now if Bob makes a transaction, the transaction is signed with a Digital Signature Algorithm using an Elliptic Curve and more precisely the secp256k1 curve ( https://en.bitcoin.it/wiki/Secp256k1). - Alice can decode the signature with Bob's public key. Actually she does not need to do that. Here is roughly what happens : - Bob constructs a transaction. A transaction unlocks some coins in order to lock them (or part of them) so that only the receiver private key can unlock them. Actually being spent some coins to your address, it is just that someone made a transaction that locks coin that only your private key can unlock. - Bob signs the transaction. To sign a message you must provide a private key, and unlocking some coins is, roughly, providing a valid signature (meaning "Hey, I have the private key !"). - The signature is then appended to the transaction (in a special field). - The transaction is broadcasted to the whole Bitcoin network. (Alice knows about the transaction but her wallet says it is unconfirmed) - The transaction is put in a block by a miner. (Alice know sees the transaction as confirmed) Alice does not have to decode the signature, when the transaction is broadcasted every node of the network checks that the signature that Bob provided to unlock the coins is valid. A valid signature is a one which is from a private key corresponding to the address for which the coin have been locked. - So, if the transaction is not hashed, how can Alice know if the transaction has been modified ? Actually hashing the message is part of ECDSA, the transaction (=the message) is hashed (with a double sha256) and this is the hash which is signed. English is not my first language so I don't know if I've been clear enough. |
|
|
|
Hi, After achieved the serialization of a raw (non-segwit) transaction with just one input and one output, I tried with multiple inputs and outputs. I managed to have it working with multiple inputs but I can't figure out how to just add another ouput (for change) without getting {'code': -26, 'message': '64: scriptpubkey'}Here is my transaction serialized and decoded in a JSON-like way : b'0100000002ee70fec3a5b90501e2e0074e21f6104b4ea4aceadc9250edc5f527250cc14148000000006b483045022100d52f6f23e0413003a2859892c33215f95475fa229e5bf7e42ce045f38c16eed902205a318926c3d9fac231fce274d82a7d84cf43acfeb71e43672ae213faf72a956301210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ffffffffffd8b15aa873de6a5f6ea0ec620083cff1bc5776130955ff44414f833500d5ac6a000000006a47304402207fed467bef68953c903d0f77f92c95e84bf2cf414936110ab89898526e095588022069f49e015aae8aff0f2e38275ca809c1b3bb2cfc48c6be47a6b0fec403ab6ba301210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ffffffffff02a0860100000000001876a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac905f0100000000001876a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac00000000'
{
version : b'01000000' ,
input_count : 2 ,
input :
prev_hash : b'ee70fec3a5b90501e2e0074e21f6104b4ea4aceadc9250edc5f527250cc14148' ,
index : b'00000000' ,
scriptsig_len : 107 ,
scriptsig : b'483045022100d52f6f23e0413003a2859892c33215f95475fa229e5bf7e42ce045f38c16eed902205a318926c3d9fac231fce274d82a7d84cf43acfeb71e43672ae213faf72a956301210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ff' ,
sequence b'ffffffff' ,
input :
prev_hash : b'd8b15aa873de6a5f6ea0ec620083cff1bc5776130955ff44414f833500d5ac6a' ,
index : b'00000000' ,
scriptsig_len : 106 ,
scriptsig : b'47304402207fed467bef68953c903d0f77f92c95e84bf2cf414936110ab89898526e095588022069f49e015aae8aff0f2e38275ca809c1b3bb2cfc48c6be47a6b0fec403ab6ba301210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ff' ,
sequence b'ffffffff' ,
output_count : 2 ,
output 0 :
value : b'a086010000000000' ,
script_length : 24 ,
scriptpubkey : b'76a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac' ,
output 1 :
value : b'905f010000000000' ,
script_length : 24 ,
scriptpubkey : b'76a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac' ,
locktime : b'00000000' ,
} I first thought that it was because my change address was the same as the receiver, but even with changing it it did not work : b'0100000002ee70fec3a5b90501e2e0074e21f6104b4ea4aceadc9250edc5f527250cc14148000000006b483045022100886d4b487aaba6c5b623e147ca41967c393efd8759489405e03f52457190c7ed022027070735086341b0e67a3add3889911153db4852cb4820dc53b0ccee89ad708101210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ffffffffffd8b15aa873de6a5f6ea0ec620083cff1bc5776130955ff44414f833500d5ac6a000000006a47304402201b96c8a2dd20c682188c2801469bad182d1b0ea059af5c9f733b9bb92bcb5f6802201e92feeb2fb98e85b04d712fcb45bff78a80bcf7fedfee66937cfc3a8bad129701210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ffffffffff02a0860100000000001876a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac905f0100000000001876a91c2150951862e39c232e7611280c03f89a84c65688ac00000000'
{
version : b'01000000' ,
input_count : 2 ,
input :
prev_hash : b'ee70fec3a5b90501e2e0074e21f6104b4ea4aceadc9250edc5f527250cc14148' ,
index : b'00000000' ,
scriptsig_len : 107 ,
scriptsig : b'483045022100886d4b487aaba6c5b623e147ca41967c393efd8759489405e03f52457190c7ed022027070735086341b0e67a3add3889911153db4852cb4820dc53b0ccee89ad708101210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ff' ,
sequence b'ffffffff' ,
input :
prev_hash : b'd8b15aa873de6a5f6ea0ec620083cff1bc5776130955ff44414f833500d5ac6a' ,
index : b'00000000' ,
scriptsig_len : 106 ,
scriptsig : b'47304402201b96c8a2dd20c682188c2801469bad182d1b0ea059af5c9f733b9bb92bcb5f6802201e92feeb2fb98e85b04d712fcb45bff78a80bcf7fedfee66937cfc3a8bad129701210388d662be197297bb54ad9927dee599f5b6731fbbb1da5c6c007fdb377054d2ff' ,
sequence b'ffffffff' ,
output_count : 2 ,
output 0 :
value : b'a086010000000000' ,
script_length : 24 ,
scriptpubkey : b'76a9c0123db6acc268de513acdbbba06a2ebacb6d56d88ac' ,
output 1 :
value : b'905f010000000000' ,
script_length : 24 ,
scriptpubkey : b'76a91c2150951862e39c232e7611280c03f89a84c65688ac' ,
locktime : b'00000000' ,
} I can't figure out what's wrong. Thank you by advance, Darosior |
|
|
|
Help me please!!! That's not how you will get helped .. cp: cannot stat `/home/ubuntu/out/src/doc/README_windows.txt': No such file or directory Maybe this should help you to solve your error. You have not answered my question : Which version of Litecoin did you fork ? However I asked my friend his Docker file and here it is (of course, you have to adapt it to your config) : FROM debian:jessie
RUN apt update -y
RUN apt-get install -y --no-install-recommends p7zip-full libgdk-pixbuf2.0-dev libtool-bin \
g++-multilib libc6-dev-i386 autoconf automake autopoint bash bison bzip2 cmake flex \
gettext git g++ gperf intltool libffi-dev libtool libltdl-dev libssl-dev libxml-parser-perl \
make openssl patch perl pkg-config python ruby scons sed unzip wget xz-utils
# Build the MXE toolchain.
RUN cd /mnt && git clone https://github.com/mxe/mxe.git \
&& cd mxe \
# Don't link Qtbase against openssl v1.1.1 that will be build (we need 1.0.2)
&& sed -i '/-openssl-linked/d' /mnt/mxe/src/qtbase.mk \
#&& sed -i "s/1.1.1a/1.0.2q/g" /mnt/mxe/src/openssl.mk \
#&& sed -i "s/fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41/5744cfcbcec2b1b48629f7354203bc1e5e9b5466998bbccc5b5fcde3b18eb684/g" /mnt/mxe/src/openssl.mk \
&& make -j4 MXE_TARGETS="i686-w64-mingw32.static" boost \
&& make -j4 MXE_TARGETS="i686-w64-mingw32.static" qttools \
# Build berkleyDB.
&& cd /mnt \
&& wget http://download.oracle.com/berkeley-db/db-5.3.28.tar.gz \
&& tar zxvf db-5.3.28.tar.gz \
&& cd /mnt/db-5.3.28 \
&& export MXE_PATH=/mnt/mxe \
&& sed -i "s/WinIoCtl.h/winioctl.h/g" src/dbinc/win_db.h \
&& mkdir build_mxe \
&& cd build_mxe \
&& CC=$MXE_PATH/usr/bin/i686-w64-mingw32.static-gcc CXX=$MXE_PATH/usr/bin/i686-w64-mingw32.static-g++ \
../dist/configure --disable-replication --enable-mingw \
--enable-cxx --host x86 --prefix=$MXE_PATH/usr/i686-w64-mingw32.static \
&& make -j4 \
&& make install \
# Can't remember the fuck is that.
&& cd /mnt \
&& CC=$MXE_PATH/usr/bin/i686-w64-mingw32.static-gcc AR=$MXE_PATH/usr/bin/i686-w64-mingw32.static-ar \
CFLAGS="-DSTATICLIB -I$MXE_PATH/usr/i686-w64-mingw32.static/include" \
LDFLAGS="-L$MXE_PATH/usr/i686-w64-mingw32.static/lib" \
# Build miniupnpc.
&& cd /mnt \
&& wget http://miniupnp.free.fr/files/miniupnpc-1.6.20120509.tar.gz \
&& tar zxvf miniupnpc-1.6.20120509.tar.gz \
&& cd /mnt/miniupnpc-1.6.20120509 \
&& CC=$MXE_PATH/usr/bin/i686-w64-mingw32.static-gcc AR=$MXE_PATH/usr/bin/i686-w64-mingw32.static-ar CFLAGS="-DSTATICLIB -I$MXE_PATH/usr/i686-w64-mingw32.static/include" LDFLAGS="-L$MXE_PATH/usr/i686-w64-mingw32.static/lib" make libminiupnpc.a \
# Copy miniupnpc to static dir of mxe.
&& mkdir $MXE_PATH/usr/i686-w64-mingw32.static/include/miniupnpc \
&& cp *.h $MXE_PATH/usr/i686-w64-mingw32.static/include/miniupnpc \
&& cp libminiupnpc.a $MXE_PATH/usr/i686-w64-mingw32.static/lib
# Rebuild openssl v1.0.2q for compatibility.
RUN cd /mnt/ \
&& export PATH=/mnt/mxe/usr/bin:$PATH \
&& wget https://www.openssl.org/source/openssl-1.0.2q.tar.gz \
&& tar -xzvf openssl-1.0.2q.tar.gz \
&& cp -R openssl-1.0.2q openssl-win32-build \
&& cd openssl-win32-build \
&& CROSS_COMPILE="i686-w64-mingw32.static-" ./Configure mingw no-asm no-shared --prefix=/mnt/mxe/usr/i686-w64-mingw32.static \
&& make -j4 \
&& make install
# Build secp256k1.
RUN cd / \
&& git clone https://github.com/profithunterscoin/phc.git \
&& export MXE_PATH=/mnt/mxe \
&& cd /phc/src/secp256k1/ \
&& chmod +x autogen.sh \
&& ./autogen.sh \
&& CC=$MXE_PATH/usr/bin/i686-w64-mingw32.static-gcc \
AR=$MXE_PATH/usr/bin/i686-w64-mingw32.static-ar \
CFLAGS="-DSTATICLIB -I$MXE_PATH/usr/i686-w64-mingw32.static/include" \
LDFLAGS="-L$MXE_PATH/usr/i686-w64-mingw32.static/lib" CROSS_COMPILE="i686-w64-mingw32.static-" ./configure --enable-module-recovery --host=i686-w64-mingw32.static \
--enable-static --disable-shared --prefix=/mnt/mxe/usr/i686-w64-mingw32.static \
&& CC=$MXE_PATH/usr/bin/i686-w64-mingw32.static-gcc \
AR=$MXE_PATH/usr/bin/i686-w64-mingw32.static-ar \
CFLAGS="-DSTATICLIB -I$MXE_PATH/usr/i686-w64-mingw32.static/include" \
LDFLAGS="-L$MXE_PATH/usr/i686-w64-mingw32.static/lib" make -j4 \
# Put libsecp256k1.la in /mnt/mxe/usr/i686-w64-mingw32.static/lib/
&& make install
# Build leveldb
RUN cd / \
&& export PATH=/mnt/mxe/usr/bin:$PATH \
&& cd phc/src/leveldb \
&& chmod +x build_detect_platform \
&& TARGET_OS=NATIVE_WINDOWS make CC=i686-w64-mingw32.static-gcc CXX=i686-w64-mingw32.static-g++ libleveldb.a libmemenv.a
#Build PHC
RUN cd /phc \
# Remove all paths that'll make the linker fail.
&& sed -i '/win32:BOOST_LIB_SUFFIX=-mgw49-mt-s-1_57/,/win32:QRENCODE_LIB_PATH=C:\/deps\/qrencode-3.4.4\/.libs/d' phc-qt.pro \
# Add -pthread to libs.
&& sed -i '/^windows:LIBS\ +=\ -lws2_32/ s/$/ -pthread/' phc-qt.pro \
&& export PATH=/mnt/mxe/usr/bin:$PATH \
&& export MXE_PATH=/mnt/mxe \
&& MXE_INCLUDE_PATH=/mnt/mxe/usr/i686-w64-mingw32.static/include \
MXE_LIB_PATH=/mnt/mxe/usr/i686-w64-mingw32.static/lib \
i686-w64-mingw32.static-qmake-qt5 \
BOOST_LIB_SUFFIX=-mt \
BOOST_THREAD_LIB_SUFFIX=_win32-mt \
BOOST_INCLUDE_PATH=$MXE_INCLUDE_PATH/boost \
BOOST_LIB_PATH=$MXE_LIB_PATH \
OPENSSL_INCLUDE_PATH=$MXE_INCLUDE_PATH/openssl \
OPENSSL_LIB_PATH=$MXE_LIB_PATH \
BDB_INCLUDE_PATH=$MXE_INCLUDE_PATH \
BDB_LIB_PATH=$MXE_LIB_PATH \
MINIUPNPC_INCLUDE_PATH=$MXE_INCLUDE_PATH \
MINIUPNPC_LIB_PATH=$MXE_LIB_PATH \
SECP256K1_INCLUDE_PATH=/phc/src/secp256k1/include \
SECP256K1_LIB_PATH= $MXE_LIB_PATH \
QMAKE_LRELEASE=/mnt/mxe/usr/i686-w64-mingw32.static/qt5/bin/lrelease phc-qt.pro \
&& make -j4 -f Makefile.Release
All credits to him, his pseudo is "Phylante". |
|
|
|
Ok, thank you both !  |
|
|
|
|
Hi,
Which version of Litecoin did you fork ? I may have a solution to your problem, a friend of me made a general solution to build Litecoin forks for Windows from Linux after he spent dozens of hours without being able to compile Insacoin. I'll point him to the discussion.
|
|
|
|
Hi, If I have no peers, who am I getting this information from? seednodes and hardcoded IPs What information am I sending and receiving? Handshakes |
|
|
|
I still would like to hear if anyone has any answer to my last message, explaining to me a valid risk of a pruned chain downloaded from another valid bitcoin peer, assuming they have some sort of forked version of that chain. I'm genuinely not convinced. I think you see it from kind of a ""user"" point of view, what we could call a "leecher" on BitTorrent. But as a Bitcoin node you also seed what you assert to be the truth, other node, some services, some user could rely on you to get information about the network and, by being a node which have fully validated the history since 2009, you can assert these informations to be the truth. You cannot assert this is the absolute truth if you trusted someone instead of verifying. For sure if you are not permitting your node to share information, this is far less risky but that's not how P2P should work. |
|
|
|
OP can set "prune=10000" or lower, though I do not recommend it, unless it is absolutely necessary because of storage space, or bandwidth limitations. He would still have to verify the chain, and that's what he doesn't want to do. |
|
|
|
|
Hi,
I'm creating raw (non-segwit) transactions and am wondering if I should specify a version >1 for a tx paying to a script hash to be valid.
|
|
|
|
|
Maybe you should just use a service provider such as blockchain.info or blockexplorer.com ?
|
|
|
|
Hi, the full blockchain (~200GB?) Yes, almost (cf https://www.blockchain.com/fr/charts/blocks-size). we can run pruned mode, and limit the size of the data to the 550 latest blocks As you mentionned running a pruned node is just usefull to avoid taking too much place. A pruned node will keep the UTXO set, and in order to form it has to check every blocks since the first. How could you get all these informations otherwise ? By trusting on or some peers ? If so, it's better not to run a node. bypass the whole verification process? Can't someone run bitcoin core, let it finish synchronizing with the network, and then just store the final state of bitcoind an replicate it on other machines? Thanks. The only truth on Bitcoin is what is written in the chain. The whole point of running a node is being kind of a new "witness" of that truth. How could you be sure of this truth if you trusted someone else ? You have to verify instead of trusting and that's what bitcoin-core is doing while you are synchronizing  . |
|
|
|
Transaction is still in memory pool but that shouln't take long because th difficulty is changed. What do you mean ? Transaction could stay in mempool for a very long time, especially on a new network. Transaction is still in memory pool I can mine properly. Meaning that you mine empty blocks even if there is a tx in the mempool ? Maybe you should check your debug.log (/home/<yourusername>/.bitcoin/debug.log) |
|
|
|
Does anyone know what should I do ?
You have to pass the option when running or . Default being, as said above, 0.0002. |
|
|
|
Hi, it means your script is evaluated to False or is empty after there is not anymore OP on the stack, it is represented as SCRIPT_ERR_EVAL_FALSE in the code, raised by the VerifyScript function ( https://github.com/bitcoin/bitcoin/blob/ce74799a3c21355b35fed923106d13a0f8133721/src/script/interpreter.cpp#L1407) or other related (witness) script verification functions. Concretely, it means that your transaction is well formed but the unlocking script doesn't satisfies the conditions set by the locking one : you have to review the ScriptSig field of your transaction. |
|
|
|
|
OK,
Thanks all for your responses !
Darosior
|
|
|
|
|
Hi,
First thanks all for your responses.
I knew about RPC commands but I wanted to confirm thay any key pair generated thanks to getnewaddress is owned by the node's owner?
Is it a bad way (/bad practice) of generating adresses ?
Thanks,
Darosior
|
|
|
|
|
HI,
sorry to up the thread but I had the same problem and the response solved it, and I'm wondering : are all keypairs generated that way ? If yes, can the node's owner dump the privkey of all addresses generated by a RPC request to it ?
Thanks,
Darosior
|
|
|
|
|
Show Posts
