Search content
Sort by
Showing 20 of 172 results by Anonymous Kid
Re: A couple of questions regarding Schnorr MuSig algorithm math notation
And finally in verification step shouldn't it be R + X~ in the following equation since they are both points, multiplication doesn't make any sense?
i think yes. when i was creating a schnorr implementation using wikipidia as a reference i was confused by this as well. but the "RX" notation actually means R + X not R*X. but it was about two months ago now so cant really remember that well.
Re: Looking for Solidty developper for brand new Tron DAPP - Full time job
Hello Guys!
I am searching for two developers to create a tron dapp together.
Our current team setup: me (dev), one marketing person who takes over the organization/coordination, one designer
But we need two other devs to get things done.
You should know: node.js, react, and smart contracts.
We want to build up a nice team for this project and for further projects... lets begin guys!
( FULL TIME JOB - REALLY GOOD EARNINGS )
Have you got a site or somewhere else to reach out to? Like a telegram/discord?I am searching for two developers to create a tron dapp together.
Our current team setup: me (dev), one marketing person who takes over the organization/coordination, one designer
But we need two other devs to get things done.
You should know: node.js, react, and smart contracts.
We want to build up a nice team for this project and for further projects... lets begin guys!
( FULL TIME JOB - REALLY GOOD EARNINGS )
Re: inbuilt transaction type in bitcoin to improve scalability massively?
Bitcoin script is pretty small as each codes only have 4 byte in size, so it only save less than 16 bytes and contribute little to reduce blockchain size growth.
Also, all wallet must adopt to this format and i doubt it can be done without hard-fork, unless you introduce new opcodes and older nodes treat it as anyone-can-spend (just like SegWit backward compatibility). Roughly it look like this where nodes automatically convert it to proper script and put the signature to correct position.
It's still has O(n) space complexity unless you're talking about MuSig Schnorr
Also, all wallet must adopt to this format and i doubt it can be done without hard-fork, unless you introduce new opcodes and older nodes treat it as anyone-can-spend (just like SegWit backward compatibility). Roughly it look like this where nodes automatically convert it to proper script and put the signature to correct position.
Quote
OP_PRESET
Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.
It's still has O(n) space complexity unless you're talking about MuSig Schnorr
I mean with this technique you can introduce signature aggregation (only need 1 signature for N keys). So it does become O(1). They main benefit is signature aggregation not getting rid of the one or two op_codes. I think you're right in that it would need a hard fork tho.
inbuilt transaction type in bitcoin to improve scalability massively?
⭐ Merited by ETFbitcoin (1)
So current tx. is (basically) like this right;
but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable?
so like this;
so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.
Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.
*i am not sure if ecdsa has signature aggregation? But I know schnorr does.
Code:
inputs;
(n times)
outputs;
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG (n times)
(n times)
outputs;
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG (n times)
but this is really boilerplate. And probably like 90% of tx. are like this^. so why not have an inbuilt method to process these tx. much easier and more scalable?
so like this;
Code:
type: simple_tx,
inputs: {
tx_id: (n times)
aggregated signature: (1 time)
}
outputs: {
type: simple_unlock
new_owner:
}
inputs: {
tx_id: (n times)
aggregated signature: (1 time)
}
outputs: {
type: simple_unlock
new_owner:
}
so here we get rid of a lot a lot of data by making tx much more simple. Node processes inputs by searching all tx_id's and makes sure they are all of the type simple_unlock. Then it adds all the pub keys for those tx up and makes sure that the input signature matches*. Then if its valid the node adds the new outputs to the db.
if simple_unlock is used with traditional scripting unlocks outputs then it just defaults to OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG and the spender has to provide a valid unlock script.
Using this method means that you can get size of input signatures down from O(n) to O(1). There is also space saving on the outputs because you only need to use a pub key and not other scripting stuff.
*i am not sure if ecdsa has signature aggregation? But I know schnorr does.
Re: What libraries for secp256k1 have been used for bitcoin in the past?
It's possible, but IMO it won't be easy to find. It's more likely we find exploit within CSPRNG/PRNG or someone put backdoor for k values of ECDSA.
How is it possible to backdoor 'k' value? I thought 'k' is generated from a hash of private key?
What libraries for secp256k1 have been used for bitcoin in the past?
Is it possible that at least one of them had an exploit in them?
Making all of the transactions/addresses sent during that period vulnerable to attack?
Making all of the transactions/addresses sent during that period vulnerable to attack?
Your description is correct - the UTXO set is reverted to the previous state and then updated for the blocks in the new chain branch. Reverting is done by means of "undo data" that is stored along each block by Bitcoin Core - and that keeps all the information necessary to revert changes made (e.g. outputs that have been spent in the block and were thus removed from the UTXO set, so that they can be added back in).
Oh i see its quite an obvious answer
. thanksso say there is one block 1500. the next block published is 1501_a. but at the same time another block is published 1501_b.
a node recieves 1501_a first and stores it as the main chain. but the next block is actually mined on top of 1502_b.
so now the node has to revert any changes made with block 1501_a. and change it so that it never happened but was instead 1501_b and then 1502_b.
how does the node revert the changes exactly?
the only thing i can think that has to be changed are, the utxo set would need to be edited to go back to 1500. and then 1501_b, 1502_b.
and the last block hash has to be changed to 1502_b as well as deleting 1501_b.
but how is the utxo set reverted? it means that utxos that were spent and deleted from the db after block 1502_a was processed, will have to some how be recovered again. how is this done?
a node recieves 1501_a first and stores it as the main chain. but the next block is actually mined on top of 1502_b.
so now the node has to revert any changes made with block 1501_a. and change it so that it never happened but was instead 1501_b and then 1502_b.
how does the node revert the changes exactly?
the only thing i can think that has to be changed are, the utxo set would need to be edited to go back to 1500. and then 1501_b, 1502_b.
and the last block hash has to be changed to 1502_b as well as deleting 1501_b.
but how is the utxo set reverted? it means that utxos that were spent and deleted from the db after block 1502_a was processed, will have to some how be recovered again. how is this done?
IS the utxo set stored independently from the block set?
Yes. It's called chainstate, few call it UTXO set.
how does bitcoin search the db for a given utxo to verify a transaction is legitimate if it just stores the blocks?
By access chainstate, not access blocks
Okay thanks. This seems like something that could be easily optimised no? Instead of having a tonne of duplicated data that is both in the utxo db and blocks db. You could have each block, and each tx that tries to spend utxo's (instead of referencing a previous tx hash), references a block number and position in the block of the tx he is trying to spend. then the client finds the tx and position of the utxo inside the tx and checks the lockscript/unlockscript.
IS the utxo set stored independently from the block set?
so for each block that comes in you store;
block (Key: BlockHash)
then extract each tx and store;
tx (Key: TxHash)
or is it all stored inside blocks? how does bitcoin search the db for a given utxo to verify a transaction is legitimate if it just stores the blocks?
so for each block that comes in you store;
block (Key: BlockHash)
then extract each tx and store;
tx (Key: TxHash)
or is it all stored inside blocks? how does bitcoin search the db for a given utxo to verify a transaction is legitimate if it just stores the blocks?
Same request and further details here:
https://bitcoin.stackexchange.com/questions/80487/how-are-blocks-verified
Thanks for asking the question there haha. i probably should have gone there first.https://bitcoin.stackexchange.com/questions/80487/how-are-blocks-verified
Achow explained pretty much what is was looking for anyway
I see in the bitcoin wiki there is something called "script" which compiles down to some bytecode to be run by a very very basic virtual machine.
Does this mean that each block is actually just a string/array of bytes when it comes in and is processed by a node?
so a block in its "true" format would look something like [0x01, 0x04, 0x0f, 0xa1.... etc. ?
and then the node that recieves the block just puts the bytes into the interpreter to be run by the bitcoin VM?
or is there some plaintext involved in the block as well? so it looks something like JSON;
{
blockhash: 12983092....,
transactions: [ {8123098...}, {12381923...}],
timestamp: "08:00:23 12/09/2017"
}
which is correct? a block is pure bytecode or JSON? what would a bitcoincore node understand when receiving a new block?
Does this mean that each block is actually just a string/array of bytes when it comes in and is processed by a node?
so a block in its "true" format would look something like [0x01, 0x04, 0x0f, 0xa1.... etc. ?
and then the node that recieves the block just puts the bytes into the interpreter to be run by the bitcoin VM?
or is there some plaintext involved in the block as well? so it looks something like JSON;
{
blockhash: 12983092....,
transactions: [ {8123098...}, {12381923...}],
timestamp: "08:00:23 12/09/2017"
}
which is correct? a block is pure bytecode or JSON? what would a bitcoincore node understand when receiving a new block?
Hi everyone
i m finding a DEV team for a project who can able to design n make a blockchain digital asset with a good securty leval
i m finding a DEV team for a project who can able to design n make a blockchain digital asset with a good securty leval
kys
Can someone create a contract that can distribute erc20 tokens to multiple
addresses by Percentage?
Ex.
Addy1 30%
Addy2 52%
Addy3 x%
..and so on.
Yes we will compensate. Please help.
addresses by Percentage?
Ex.
Addy1 30%
Addy2 52%
Addy3 x%
..and so on.
Yes we will compensate. Please help.
sure, send me a pm. can it do for $59.
Oh wait. I just realised that all integers belong to a finite integer field of [1, n-1].
So you have to do finite field math or whatever its called.
so thats how k^-1 is calculated. someone please correct me if im wrong... or tell me if im right lol. im still not sure if thats correct
So you have to do finite field math or whatever its called.
Quote
The tricky one is division; that is not division on the field of integers followed by a modulus operation. Instead, it involves finding the multiplicative inverse of a number; that is, given b, we find the field member b^−1 such that b×b^−1=1. Then, a/b=a×b^−1
so thats how k^-1 is calculated. someone please correct me if im wrong... or tell me if im right lol. im still not sure if thats correct
from wikipedia
But how can s be an integer since k^-1 will yield a decimal amount (e.g. 123.12347)?
Quote
G is a basepoint on a curve.
Alice picks a key; d_{A} and a corresponding pub key; Q_{A} = d_{A} * G
Calculate e = HASH(m), where HASH is a cryptographic hash function, such as SHA-2.
Let z be the L_{n} leftmost bits of e, where L_{n} is the bit length of the group order n.
Select a cryptographically secure random integer k from [1,n-1].
Calculate the curve point (x_1, y_1) = k * G.
Calculate r = x_1 mod n. If r = 0, go back to step 3.
Calculate s=k^-1(z+rd_{A}) mod n. If s=0, go back to step 3.
The signature is the pair (r,s).
Alice picks a key; d_{A} and a corresponding pub key; Q_{A} = d_{A} * G
Calculate e = HASH(m), where HASH is a cryptographic hash function, such as SHA-2.
Let z be the L_{n} leftmost bits of e, where L_{n} is the bit length of the group order n.
Select a cryptographically secure random integer k from [1,n-1].
Calculate the curve point (x_1, y_1) = k * G.
Calculate r = x_1 mod n. If r = 0, go back to step 3.
Calculate s=k^-1(z+rd_{A}) mod n. If s=0, go back to step 3.
The signature is the pair (r,s).
But how can s be an integer since k^-1 will yield a decimal amount (e.g. 123.12347)?
Re: How is a bitcoin transaction serialised so that it is ready for signing?
What are the exact technical steps to serialize a transactions so that it is ready to be signed and the resulting signature is valid?
You mean something like this? https://bitcoin.stackexchange.com/a/32695This answer is also pretty constructive (And is what the above answer is based on). https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx?noredirect=1&lq=1
The above answer also links an article which is defnitely worth a read. See http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
I'd be very much interested in seeing a segwit version of this aswell. especially one which uses bech adresses. (If anyone has any links!)
Why does the hex transaction need to be decoded?
Code:
HEX_TRANSACTION="010000000126c07ece0bce7cda0ccd14d99e205f118cde27e83dd75da7b141fe487b5528fb000000008b48304502202b7e37831273d74c8b5b1956c23e79acd660635a8d1063d413c50b218eb6bc8a022100a10a3a7b5aaa0f07827207daf81f718f51eeac96695cf1ef9f2020f21a0de02f01410452684bce6797a0a50d028e9632be0c2a7e5031b710972c2a3285520fb29fcd4ecfb5fc2bf86a1e7578e4f8a305eeb341d1c6fc0173e5837e2d3c7b178aade078ffffffff02b06c191e010000001976a9143564a74f9ddb4372301c49154605573d7d1a88fe88ac00e1f505000000001976a914010966776006953d5567439e5e39f86a0d273bee88ac00000000"
tx_data=HEX_TRANSACTION.decode('hex_codec')
tx_hash=double_sha256(tx_data)
tx_data=HEX_TRANSACTION.decode('hex_codec')
tx_hash=double_sha256(tx_data)
wouldnt the whole process work just as fine as
Code:
tx_hash = double_sha256(HEX_TRANSACTION)
. Whats the reasoning for adding this extra step?