Bitcoin Forum
February 21, 2019, 01:04:24 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 ... 551 »
1361  Bitcoin / Development & Technical Discussion / Re: What? New type of bitcoin adresses??? on: September 28, 2017, 03:47:17 PM
I was browsing through blockchain today and I noticed new - weird looking adresses like this bc1qdl753ur9ucwa3cgfrud2nqvu7k69dykk3cwwx6g64a5szn3xw92sp8mc7a.
What block explorer was showing these?

What type are these???
These addresses are bech32 addresses. They are for the native segwit output type. They are specified in BIP 173

How would you create transactions with those?
As you would with any other type of address. The wallet software will handle it for you. If the wallet software supports bech32 addresses, it will know how to decode them and create transactions with them. These addresses specifically tell the wallet what type segwit output to create.

They are some sort of witness adresses?
Yes.

Each address has a private key, the ones start with 3 have 2/3 private keys, what type of a private key would have this one?
It depends.

First of all, addresses starting with a 3 do not necessarily have private keys associated with them, and not necessarily 2 or 3 private keys. Addresses starting with a 3 are P2SH addresses which means they have a script associated with them, and that script can be whatever you want so long as it is a valid script. This means that it can contain many public keys (and thus have many private keys) or no public keys (and thus be associated with no private keys).

bech32 addresses are for the P2WPKH and P2WSH output types. For P2WPKH, there is one private key. P2WSH is like P2SH; it is associated with an arbitrary script.

Also, there are no types of private keys. All private keys are the same "type"': a 256 bit integer.

Are they more secure?
How do you define "more secure"?

Bech32 addresses have built in error detection and correction (they can correct, but software should not be automatically correcting errors). I don't think they are any more or less secure than "normal" addresses.
1362  Bitcoin / Bitcoin Technical Support / Re: version 15.0.1 hangs when "done Loading" windows 10 64bit on: September 28, 2017, 03:38:40 PM
Here's the debug log
Post all of it. The little snippet you posted is irrelevant.

....why would the handshake be timing out?
The peer that Bitcoin Core tried to connect to that time did not respond to the version message. This is normal behavior; sometimes nodes just aren't online when you try to connect to them.
1363  Bitcoin / Development & Technical Discussion / Re: Lightning Network Question: Cost to open / close a channel on: September 28, 2017, 03:34:09 PM
As far as I understood a LN Channel is open and closed by their participants by broadcasting and confirming transactions on the chain, so they only pay those transactions fees and not all the other they may do while the channel is open.
Yes.

If that is right, the LN would work only for recurrent payments and not occasional transactions, right?
Kind of. Having an open payment channel with one party is really only good for recurring payments. However the lightning network expands beyond the one channel. You can have a channel open with someone who has a channel open with other people, and they have channels open with other people and so on. One of the main ideas of LN is that you can send occasional transactions by routing a payment through multiple payment channels that people have open with each other.

Suppose Person A has a channel open with B, and B has one with C. If A wanted to pay C, they could send money to B and B sends money to C via their respective open payment channels. The transactions used for this sending are special and make it so that the money will only actually move under specific circumstances. These transactions are called Hashed Timelocked Contracts. They make it so that B can only get the money from A if they have forwarded the money to C.
1364  Bitcoin / Development & Technical Discussion / Re: Lightning network compared to Dash and IOTA on: September 28, 2017, 03:25:48 PM
My question is - is Lightning Network really going to lock our funds for so long time that its going to cause problems?
No, it is not. When you "lock" your funds in a LN payment channel, you can still spend those coins, albeit only with the other party in the channel. However with LN, if that other party is connected to other people via payment channels, you can make payments to those other people and the people they are connected to and so on and so forth. So your funds aren't "locked"; you can still spend them and move coins to other people that have LN channels open. Furthermore you can choose to close a channel at any time that you want and be able to access your coins as soon as the channel closing transaction confirms. There is no set time limit on a channel and there is no minimum time required for a channel to be opened.

Cause it seems to me obvious that hackers could fail transactions for purpose and block the network.
What do you mean by "fail transactions"?



The lightning network is different from DASH and IOTA in that it itself is Bitcoin, not an altcoin. With LN, you are moving and using Bitcoin so the value you move is fixed and does not change. If you were to use an altcoin in the same manner, you would risk losing money as the altcoin's value compared to Bitcoin's changes. Furthermore, many of the security risks and potential attack vectors are fairly well known because LN uses Bitcoin and Bitcoin's security risks and potential attack vectors are well known. With an altcoin that uses some crazy cryptography that may not necessarily be secure (IOTA had some broken cryptography which were pointed out in a security review done by 3 MIT DCI researchers) does not have known security risks and potential attack vectors.
1365  Bitcoin / Development & Technical Discussion / Re: Share your opinions of the November Lightning Fork on: September 27, 2017, 03:29:08 AM
So, Lightning is not a UAHF, but is going to pass because Segwit already was implemented?  It's a done deal, or....am I totally missing something?
Lightning is neither a hard fork nor a soft fork. It will be deployed on the main network because Segwit has already activated. There is nothing to "pass". Lightning is not a consensus rule change; nothing needs to be activated or passed in order for it to be deployed. It just needs to be implemented. By deployed, I mean used.
1366  Bitcoin / Project Development / Re: [ANN] Bitcoin Transaction Fee Booster on: September 26, 2017, 08:24:47 PM
Hello. I used Feebooster as receiver (created raw tx and signed) but it seems that it decoded Hash 160 into the wrong address, not the one I filled in (with version byte of 0x01 for P2PKH) but it sent to the wrong one (version byte of 0x05 for P2SH). No idea how and why that happened.
Funds were sent to a different address (starting with 3) than the one I filed in, and bot have same Hash 160.
Post the raw transactions, screenshots of what you entered, and the txids of any and all transactions involved (including the one you are bumping and the bumping tx).
1367  Bitcoin / Development & Technical Discussion / Re: What are these variables in the Genesis Block and how were they determined? on: September 26, 2017, 08:23:57 PM
First of all, please do not use or refer to the Bitcoin Core 0.8 codebase. It is extremely outdated and insecure.

Could anyone help me out in figuring out what the numbers in the first one mean.
It is just making a script to put in the scriptSig of the only transaction in the genesis block. The stuff in the script mean nothing and have no consensus meaning except for the fact that they must be there otherwise the genesis block's hash will not match what it is supposed to be.
Code:
<< 486604799
Push this number to the scriptSig. It just happens to be the decimal version of the nBits of the genesis block.

Code:
<< CBigNum(4)
Push the number 4 to the scriptSig.

Code:
<< vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
Push the character array pszTimestamp to the scriptSig. This character array is just the string of "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

And for the second one, where is that hash from??
That is not a hash. That is a public key. It is a normal Pay to Public Key output.



The forum is doing something weird with the code blocks here.
1368  Bitcoin / Bitcoin Technical Support / Re: transaction history and storage requirement on: September 26, 2017, 03:41:42 PM
From what I am reading, what is stored on the individual computing nodes is a history of hashed transactions and stuff.   
No, not the hashed transactions, the full transactions. And the block headers for the block that a transaction is in.

At some point in the past a miner received a coin as payment and a block starts ( a linked list, some structure of some kind) and grows keeping track of transactions.
No, that is not how the blockchain started. The first block (known as the genesis block) was created by satoshi and hard coded it into the software (and it still is hard coded). You cannot receive something as payment if it does not yet exist; coins only exist because blocks exist. The linked list known as the blockchain is built off of the genesis block.

1)  Does this mean that all transactions since startup are still in the system?
Yes.

2)  Will they all stay there for the next 25, 50, 100 ...... years?
Yes. They have to.
1369  Bitcoin / Development & Technical Discussion / Re: Segwit and Lighting network on: September 26, 2017, 03:36:19 PM
Yes I know, but I meant only segwit. I know Core is not supporting 2x.
So which is the first version released by Core with segwit?  
Bitcoin Core 0.13.0/.1 (0.13.0 had it implemented but had no deployment mechanism for segwit. 0.13.1 had the actual deployment parameters)

Block weight is a segwit specific thing and is only implemented and defined in segwit.

Same thing for comparison schema or slide ... are there some pictures showing block data structure and verification rules changed before and after segwit?
Thanks.
Read BIPs 141, 143, and 144
1370  Alternate cryptocurrencies / Altcoin Discussion / Re: How to set up node on: September 26, 2017, 02:45:20 PM
Set some hard coded seed nodes to be nodes that you know will be up for a long time.

Set up a DNS seeder and add that to the hard coded list of DNS seeders.
1371  Bitcoin / Development & Technical Discussion / MOVED: How to set up node on: September 26, 2017, 02:44:44 PM
This topic has been moved to Trashcan.

Duplicate
1372  Bitcoin / Development & Technical Discussion / Re: Segwit and Lighting network on: September 26, 2017, 02:42:16 PM
Cool, thanks for your reply.
When has it been released? I've compared bitcoin core 0.15.0.1 with 0.14.1 and MAX_BLOCK_WEIGHT (should be the right constant to check) is the same.
Does anyone know where to find a document, pdf, slides, ... with a graphical comparison schema of the differences before and after segwit?
Segwit and Segwit2x are not the same thing. Segwit has already activated, segwit2x has not. Bitcoin Core does not support segwit2x so you won't find any code related to segwit2x in the Bitcoin Core codebase.
1373  Bitcoin / Bitcoin Technical Support / MOVED: Post not being active on: September 26, 2017, 02:35:34 PM
This topic has been moved to Trashcan.

Please read the stickied topics in meta about ranks and activity: https://bitcointalk.org/index.php?topic=703657.0, https://bitcointalk.org/index.php?topic=237597.msg2513302#msg2513302, https://bitcointalk.org/index.php?topic=178608.0
1374  Bitcoin / Armory / Re: FRAGMENTED BACKUPS VULNERABILITY!! IF YOU USE THEM, READ THIS!! on: September 26, 2017, 12:58:01 AM
Entropy , used by many to create SSS fragments for cold storage uses a similar scheme -

https://github.com/mycelium-com/entropy

Specification -

https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki
The SSS implementation in Armory is completely unrelated to that. It also predates that by a few years.
1375  Bitcoin / Development & Technical Discussion / Re: Segwit and Lighting network on: September 25, 2017, 08:44:36 PM
@anonymoustroll420: strictly speaking it is not a blocksize increase. Stuff has been moved in another place to make room for other transactions.
As far as I know blocksize is the same and that's the reason for "2x or not 2x". But this is another story.
No, that is strictly false. Segwit is a block size increase; the size of a block message can be up to 4 MB now. 2x is yet another block size increase; it makes the maximum 8 MB.
1376  Bitcoin / Armory / Re: BDM Error? armory 0.93.3 on: September 25, 2017, 07:01:54 PM
You are using a version of Bitcoin Core which is incompatible with your version of Armory because it has segwit enabled. Either downgrade to Bitcoin Core 0.12.x (and redownload the blockchain) or upgrade Armory to 0.95.1 or greater.
1377  Other / Meta / Re: my account has been frozen how i make it unfrozen? on: September 25, 2017, 05:57:39 PM
Account for what?
1378  Alternate cryptocurrencies / Altcoin Discussion / Re: 2X on: September 25, 2017, 03:49:36 PM
Quote
2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.
Thanks just to clarify, when I say 2x, I know segwit gives effective size, but I mean the commitment to make base blocks bigger so we can really make the "spammers" run ou of money and keep on chain fees lower, and give consumer choice.
With 2x, the worst case size is ~8 MB. We don't know how such large blocks will effect the network. It could increase orphan rates, it could cause many nodes to drop off of the network because they can't handle the additional load. We don't know if the network can handle such larger blocks. Just because your internet connection can and your machine can handle the load does not mean that everyone around the world who is running the node can. They may be restricted by things like the Great Firewall of China which may find larger blocks easier to spot and thus make Bitcoin easier for them to block entirely.

Furthermore larger blocks can lead to miner behavior that is detrimental to the network. If the mempool is constantly cleared by a new block, then miners may be more incentivized to perform fee sniping instead of moving the blockchain forward. That is not good for the network.

Why does the "base block size" need to be bigger to stop spammers? You don't think they aren't going to also use segwit? Spammers can use segwit and pay less in fees than they would with a non-segwit transactions, and make more spam that fits in a block. If you double the maximum block weight, you depress fees even more and let spammers pay even less to spam transactions.

Also on point what then isentivices miners as block reward drops if they don't have enough transactions on chain?
Having more transactions on chain does not necessarily correspond to having more transaction fees in a block. If the general idea is that larger blocks will decrease fees, then that means that more transactions need to be made at a lower fee rate in order for total transaction fees to match the fees for when blocks were smaller. Currently transaction fees are pretty low anyways except the times when people are spamming transactions (and it is very noticeable when that happens because the number of transactions in the mempool at a certain fee rate inorganically shoots up).
1379  Bitcoin / Development & Technical Discussion / Re: Bind an address to only be able to send to another pre specified address? on: September 25, 2017, 03:24:49 PM
ok thanks....I was kinda thinking along the lines of using the signed specified address as a requirement combined with the part of the priv key, hashed or otherwise, that then produces the whole private key, but only as a signed transaction for the sending address.

That way you would never have access to the privkey of the sending address, excepting for using the signed predetermined receiving address.

...I may be way of base here, but it seems possible?

or put another way, like a contract function that says, if you enter address 2 and your part of the private key or private key, then we will use that to sign the whole transaction and send it off to address 2. The contract only works in it receives the address 2 and your signed address 1.....?
Again, inputs and outputs are unrelated to each other. Inputs cannot access any data outside of the input itself. Inputs have no idea what the outputs are and cannot access the outputs to do anything.

Also, there are no such things as addresses to the Bitcoin network. Only transaction outputs. Addresses are just an abstraction for us humans.
1380  Bitcoin / Bitcoin Technical Support / Re: Getting a new phone. on: September 25, 2017, 03:13:00 PM
This thread is being locked because the OP has not responded in a while and it is just becoming full of spam.
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 ... 551 »
Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!