 Show Posts
|
|
Pages: [1] 2 »
|
|
By developers I mean people who maintain Bitcoin client software. For example, the fork happens when the bitcoin rules change and it is the developers who make those changes. Who pays them?
|
|
|
|
|
Hello!
Could anyone tell who are those bitcoin developers that update bitcoin rules? How do they get paid for their work?
Thanks!
|
|
|
|
|
Thank you very much for answering! As I see it:
1. scriptSig is an input of the "redeeming" transaction (the one where I want to spend previously earned bitcoins) and scriptPubKey is an output specified in the "referenced" transaction (the one where I earned those bitcoins that I'm trying to spend now).
2. To see if I'm allowed to spend those bitcoins, a miner will concatenate scriptSig and scriptPubKey and run the resulting script.
3. From scriptSig signature and public key come out. This public key is then hashed and compared with the hash of the public key specified in scriptPubKey. This is the first check for validity of the transaction. The second check if for the signature.
Question: in step 3, how to get the public key from scriptSig? In simple terms, I give you scriptSig, will you be able to tell the public key?
|
|
|
|
What exactly is a fork when it comes to bitcoin? Will other coins also Fork? Will Bitcoin continue to Fork later on down the line?
When developers want to make a change to the the code or rules that govern a crypto-currency's blockchain (and because blockchain networks are decentralized) they need to propose that new change to all the node owners. They way they do that is by declaring a date and time to enact the new code and then allow each node owner to select if they want to adopt the new code or not. This action creates a fork of the existing blockchain (like a fork in a road). Some node owners may choose the new path (the fork) and some may not. The blockchain that majority of node owners select technically is the winner, but the forked version can remain in existence if node owners keep it going. To keep owners of the original cryptocurrency interested in trying the newly created/forked cryptocurrency, the developers give an amount of the newly created cryptocurrency that each wallet owner holds of the existing target cryptocurrency. This action is called the "airdrop", because you're granted coins for nothing - you don't have to buy them, you don't have to work for them. There will continue to be forks as long as developers keep proposing alterations to an existing cryptocurrency. That's pretty much it. If you have questions, there are a lot of people that can answer them. This is a very clear answer! But it raises the following question: who are those developers (location, how many, etc.)? Who pays them? From your answer it seems like they can award coins by their will. |
|
|
|
|
In this input of a transaction
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
where is the public key?
|
|
|
|
Hello! Could someone explain how <signature> and <public key> come out of scriptSig script? Of course, scriptSig in not equal concatenate(<signature>,<public key>). How is this information incorporated into scriptSig? Thank you! |
|
|
|
that is not a fork. what you say is a bunch of terminology regarding new blocks and what happens to them in different cases like when the block has not parent. read it here: https://bitcoin.stackexchange.com/questions/5859/what-are-orphaned-and-stale-blocksa fork in programming is when you "copy the original code" for yourself to change it. but a fork in bitcoin is when you change the "rules" of bitcoin. for example changing consensus rules about block size. some refer to it as "making something that was invalid before, valid. or making something that was valid before, invalid" in case of the list i mentioned here, these people are changing something about bitcoin. some increase the block size some change the algorithm, change the supply,... this change results in a new chain and a new coin which we call an "altcoin". Well...what kind of fork they are talking about here https://www.cryptocompare.com/coins/guides/what-is-a-bitcoin-fork/ Your answer is inconsistent with that article. Is it difference in terminology? |
|
|
|
|
Big thanks to all who responded! I want to know the role that bitcoin scripts play in bitcoin transaction output. In other words, assume there are no scripts in bitcoin's transaction output and only a public key is there, what exactly will be impossible under this assumption? My question came from the following line in a textbook on Bitcoins: "...we study the Bitcoin scripting language and come to understand why a script is used [...in transaction's output...] instead of simply assigning a public key". But the book does a poor job in explaining it. That's why I'm asking it here. Thanks is advance for your patience with newbies :-)
|
|
|
|
|
Dear forum members, I would like to ask you again! Could someone answer my question from the previous message? I would really appreciate it!
|
|
|
|
which one?  there are currently at least 10 forks planned to happen! and some of them already happened. here is a list of forks that i know of: name -------------- block height for snapshot | Super Bitcoin | || | 498888 | | Bitcoin Platinum | || | 498533 | | Lightning Bitcoin | || | 499999 | | Bitcoin Platinum | || | 500000 | | Bitcoin Uranium | || | 500000 | | Bitcoin God | || | 501225 | | Bitcoin Cash Plus | || | 501407 | | New Year Bitcoin | || | 520101 | | Bitcoin_Diamond | || | TBD | | Bitcoin_Silver | || | TBD |
some of these may not be accurate because sources are different and they may also change. p.s. Current Block HeightI'm confused... Could you please explain? Forks occur when blocks are found within few seconds of each other, implying that one of them will eventually been orphaned. What is that list of forks that you gave above? How did they occur? |
|
|
|
|
Hello!
I'm trying to understand Bitcoin scripts, but it seems like all sources that I find on the Internet assume that the reader has computer science background. For example, "Each transaction output doesn't just specify a public key. It actually specifies a script". Why? What's the problem with specifying just a public key? What breaks down in the design of Bitcoin if we don't use any scripts?
|
|
|
|
You are correct, except that your block will be rejected or eventually forgotten by everyone else but you. Nodes typically only keep the blocks in the longest chain, though they may keep orphaned blocks for a little while in case they somehow becomes the longest chain.
Thanks, but doesn't "...a little while..." proves that most of the time the nodes will have different versions of the ledger (some nodes will keep transactions a little longer than others)? |
|
|
|
The ledger is added to every 10 minutes of so. When you broadcast to the network that you have found a block your transaction is tested. At any point along the way if you have errors then the block is dropped. You need to have the hash of the previous block plus have met the diff goal on your block. This will be checked. If you have not met the diff then the block is rejected out of hand by the network.
Now, if you did meet the diff requirements then you have, indeed found a block and added it to the blockchain.
You use words " dropped", " rejected" without explaining how this is technically implemented. So far, only one thing is clear: the block is in the blockchain if it receives confirmations (consensus in the network). "Confirmation" means that subsequent blocks include its hash as the previous block's hash. But what happens to the blocks that were proposed, but for various reasons didn't end up in the longest chain? Are those still in the ledger? |
|
|
|
One needs to find a correct hash to claim a block. Once you have done this work you need to do it again, again in order for your block to become the longest and for other miners to consider you branch to be the correct one. If you have half the hash power of the entire network you would expect to get every other block (over time) but, with half the hashpower. it is not inconceivable for you to get 5 blocks in a row (1:32) or even 10 in a row (1:1024).
Today, 2017, it's virtually impossible for one entity (not talking about a mining pool here) to get half the network hashrate. Still - there are scenarios where 51% attacks are possible.
My claim is stronger: with probability 1 a 51% attacker will be successful (as I see it, it follows from Satoshi's paper). What about the ordering question: What is the attacker's gain of changing the ordering of transactions? |
|
|
|
|
Hello!
Could someone verify if the following is true (my understanding of distributed ledger concept as applied to Bitcoin).
Each node of the network (miners and all other nodes that run Bitcoin client) has a copy of the ledger. Thus, the ledger is stored by the nodes (it is distributed in exactly this sense!). The ledger is periodically updated with new blocks of transactions being sent to the nodes. Hypothetically: If I am a miner and want to create a fork I can easily do it by creating a block and sending it to the network and the network will add it to the ledger. For example, for the chain A-B-C-D, I can add a block B2 to B, thereby creating a fork at node B. Of course, this block will most likely be orphaned because it is not the longest branch and the miner did it, say, for fun. Is my understanding right? If not, please point out what is not right.
Thank you in advance!
|
|
|
|
I assume by "it" you mean "an attacker". It seems to me a bit clear now, but... just to make sure I understand it right. Based on my understanding of Satoshi's paper it follows that 51% attacker will be able to extend any block in the chain with probability 1 (provided the attacker has unlimited resources). Is this true? And my second question: according to your first link:"...exclude and modify the ordering of transactions". What is the attacker's gain of changing the ordering of transactions? Thanks! |
|
|
|
Thanks! If I understand it right, a successful attacker will have to win (solve the puzzles faster than other nodes) several times in a row and create a longer branch. After that all other nodes will follow the rule of extending the longest chain. Right? |
|
|
|
Could you please elaborate a little on this? According to your link: "Realistically, an attacker would only be able to modify transactions within the past few blocks." How is that not changing the ledgers? That's exactly what I don't understand. The ledger is distributed, and yet it could be altered by an attacker. Unless an attacker could hack everyone's computer and replace their ledgers with his dishonest version??? |
|
|
|
|
