|
Bitcoin 0.12.0 has finally been tagged. The official release should be in a day or two after all of the gitian builds are finished.
|
|
|
|
|
While that could potentially work the problem is that transactions could actually become lost. By doing this, transactions aren't actually included in the blockchain. It would require nodes to store all of the transactions and then those nodes need to request the transaction from other nodes. Then, when scanning the blockchain, a node would have an additional network overhead because it has to ask other nodes for all of those transactions. It also makes the blockchain not a permanent place to store transaction data.
|
|
|
|
i think you may have a much easier time if you install virtual box and get a windows 7 iso image and install everything clean , i have not used win 10 yet for anything except the demo and not on an actual machine only in vb..... still i know others who have had no issue with building on win 10 , from experience if you are new to compiling a bitcoin client for win from these notes believe me a clean install as i suggested should be a big help.
I will try that later, for now I have figured out how to cross compile it on Linux. I would bet that you've yourselves unintentionally damaged one of the source files. I see "ragne" instead of "range", like somebody messed some include files and then tried to repair them by hand.
No, that is just a typo. I couldn't actually copy and paste the error so I typed it out. |
|
|
|
2 - I could connect to multiple people/businesses through one channel (and be able to both pay/receive).
I know both aren't exclusive, so more of a question whether option 2 is possible.
I don't think it is actually possible to open a channel in which there are multiple parties. However part of the lightning network is to use hops through multiple channels to reach another party that you want to pay. The problem with that is timing as I think using that method is rather inefficient, especially for something that needs to happen quickly as it relies on everyone in between to act quickly. Furthermore, if the hops charge fees, then the transaction fee for that transaction could grow very quickly if many hops are involved. It also requires that each hop have an open channel to another hop and that may not always be the case, or at least it would require several hops. For those one time payments, going through all of those hops would probably be inefficient. For your everyday coffee that may not be purchased from the same merchant, there could be a network of coffee merchants so that you can still pay for your coffee through lightning by routing it through several different merchants but you only need a channel to one merchant. |
|
|
|
After 750 of the last 1000 blocks signal support for the fork by setting a certain bit in the version number
Thanks for the explanation, to clarify, does it have to be 750 consecutive blocks in a row with that new version or is it just 750 out of the last 1000 blocks that will trigger the grace period? Just 750 of the last 1000, it doesn't need to be consecutive. |
|
|
|
Hmm, no it's not? Unless you have a habit of buying it on regular basis (every day) from the same merchant. To avoid confusion, "coffee" is commonly used as synonym for small to medium everyday transactions (whether recurring or not).
Well that's contradictory, an everyday transaction is, by definition, recurring, is it not? It happens every day. Let's use other example, I want to buy Raspberry Pi with bitcoins, what do I do? Will it be possible, will I get penalised with (artificially driven up) high fee?
I would not consider a raspberry pi to be a small purchase. To me small purchases are less than $10. It is also not comparable to the price of a coffee. Since a raspberry pi is a one time, not really small purchase, it would happen on chain. Again, one time payments would happen on chain. It is not efficient to do those over lightning. |
|
|
|
|
There will probably be no fork to switch to bitcoin classic. The forking method used by classic is not the definitive forking method and not all hard forks will deploy this way. Soft forks also deploy differently.
Here is how it works:
After 750 of the last 1000 blocks signal support for the fork by setting a certain bit in the version number, the fork will be set to occur. After a 28 day grace period following the last block of that 1000 blocks, the fork will officially happen with the production of a block larger than 1Mb. The grace period is for everyone who hasn't upgraded to upgrade.
|
|
|
|
There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312) They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had. What about merging in this branch: https://github.com/etotheipi/BitcoinArmory/tree/autotools-gitian from the original repo? Needs rebase obviously. |
|
|
|
|
You could try reindexing again. Or you could also just try a different wallet which doesn't require the full blockchain. If you go with another wallet, I recommend that you use Electrum. You will need to export your private keys from Bitcoin Core and import them to Electrum.
|
|
|
|
So is there a way to verify in a away your wallet so no one else ever use it even if generating the same wallet is extremely low?
Once you create the wallet you could check the master public key of the wallet on a block explorer and see if any of the addresses have been used. This is unnecessary though. |
|
|
|
Speed of light doesn't a concern in 100 years (only 1-2 minutes between Mars and Earth) but after that there is no money or crypto at this rate...
Actually, a radio signal can take between three and twenty-one minutes to get from Earth to Mars, and that's just for a one-way communication. That's why the Mars rover teams always have to plan their activities so carefully. If they detect that their rover is about to get stuck or slide off a cliff or something, it may already be too late to do anything about it. That's why I brought up the time delay problem. With the time delay many transactions probably wouldn't be able to happen on chain. They would most likely need to be off chain transactions. Additionally, I don't think there is a lot of bandwidth but that could probably be remedied with a decently powerful transmitter. There are also issues with nighttime on Mars as during the night the only way to get communication to Earth would require sending signals to orbiters which relay to other orbiters which can then broadcast back to Earth and vice versa. Using Bitcoin would require this constant communication and those orbiters would need to be able to handle a lot of data and handle it quickly. Also, IIRC there is a few weeks when there is a communications blackout because Mars is on the opposite side of the Sun. It would be difficult to have on chain transactions while we still used radio, but once we get faster-than-light communications, that should become a non-issue. For now though, it would probably become having a Mars sidechain which is linked to the main Bitcoin blockchain. |
|
|
|
I don't think you got my point.
First of all, lets ignore potential high BTC price, I'm specifically referring to situation where block subsidies are irrelevant or non existent.
This system is internally conflicted. To dumb it down: to keep small blocks (and for LN to get/keep traction) you need high fees (the smaller the block-size, the higher the fees). While users need low fees (otherwise BTC becomes completely unattractive and will lose to altcoins/fiat).
For that to work you would need to have some sort of constant balance, basically you'll need to find a way to keep average tx fee on optimal level (if such can be determined), keep number of on-chain txs on high enough level, prevent the channels to be open for too long (to enforce open/close on-chain fees) but let them be open long enough (to keep LN usable). On top of that you would need to be able to adjust the max block size ad hoc (both increase or decrease if needed) to adjust to current needs. Essentially you'd need central planning to get this thing somewhat working. Also, you would definitely need much bigger blocks.
The above would also require 'fee market' (keeping txs/sec capacity below the demand) which is a flaw on its own. If you had constant demand of 10 tx/sec and capacity of 7 tx/sec, that means even if all of the 10 senders put all of their wealth on paying tx fee, at least 3 txs don't go through. That's not what reliable, sustainable model looks like.
The lightning network still requires transactions to occur on the blockchain. There still needs to be transactions to fund the payment channel and to close out the channel so that the Bitcoin can be spent elsewhere. That would be the source of the fees as well as other on chain transactions. From what I understand, lightning is not very useful for one time payments. It is less efficient and effective for me to pay for something through lightning that I only do once every so often, e.g. buying a new computer. Those types of transactions would still occur on chain. What lightning is good for is for recurring payments and microtransactions like those from faucets. Instead of having a bunch of transactions with tiny outputs from faucets, there is instead one transaction to close the payment channel when the faucet user wants to spend his Bitcoins somewhere else. Furthermore people will have to reload their balance when they run out so they must close the payment channel and open a new one with more Bitcoin to be able to pay more. It basically isn't possible to stay off-chain all the time, you will have to make some transactions that are on chain. So basically the funding and closing transactions are the sources of fees as well as other one-time payments and transfers and such that do not need lightning. It isn't possible First of all we can definitely afford to increase the blocksize to two megabytes in terms of hardrive space today, you should know better then to use that argument, and again I am saying that it can reflect the technological limits of today.
Not necessarily. It isn't just about hard drive space. There is also the thing with hashing which doesn't scale linearly. That requires computing power and by doubling the block size, the computing power required is quadrupled so the time required to verify the block is quadrupled. That is something like a couple of seconds but in today's fast paced world where everything is about being faster, those few seconds are an extremely long time. Additionally, there are problems with the size of the blockchain itself The sheer size of the blockchain makes downloading it take an incredibly long time. With larger blocks, the blockchain will grow faster. That means that more time will be needed to download the full thing for full nodes, more bandwidth is required, and more storage space is required. Not everyone has the bandwidth to download the entire blockchain nor able to support the amount of bandwidth that a full node consumes, which will also go up with a larger block size. I am not entirely opposed to having a small block size increase, but I think that we definitely need segwit for its actual purpose of preventing transaction malleability and the side benefits of enabling other scaling solutions that don't require block size increases. In the long run, I don't think that increasing the blocksize is sustainable. Also, for everyone complaining about lack of dates, the timeline is listed right here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/ |
|
|
|
the wallet will generate a large random number and this is your master private key Why is not possible to create this twice on another offline computer?How it knows the second computer that the first computer create a master key and which one so it will not create the same? As both can be offline ..... It doesn't. However, the range of possible random numbers and with a decent random number generator, the probability of two computers randomly generating the same number is extremely low. This is the basis for pretty much everything in cryptography: that the odds of two devices randomly generating the same random number is so low as to be negligible. Online wallets do the same thing. They don't check the blockchain to see if the address has been used previously when it generates the address. There is simply no need to do so. |
|
|
|
How am I possible to rebroadcast it ? It is payment from someone else to me, not from mine wallet
Anyone can rebroadcast a transaction, as I just did it with those three. As for how to do it, the easiest way is to just use a transaction broadcasting service like https://blockchain.info/pushtx or https://live.blockcypher.com/btc/pushtx/. You can also do it from your wallet but it depends on the wallet that you are using. |
|
|
|
The fees on the transactions which supply the inputs to your transaction are very low. It is probably not safe to accept that payment as it has a decent chance of a double spend being successful. As for how long, nobody knows. It could take some more time for it to confirm. To help it along, you could rebroadcast the transactions so that the network doesn't drop them. That will give it a higher chance of being confirmed. These are the raw hex of each transaction 025f169b12a89a1833b8184bea03320dfaf2cebe743c4c00b543aa1e2c91d5a3 0100000008383bd820835e1297116b9acfea10b030ef8986d066f40dea6f4c94dafd2d6b24000000006a47304402201564d6fe703a4b5ad31168c9de242c30a152f7cec3a81ab91b0d0917511c8c4a0220104c07ceb5f1e4e907dde2ec64e9b06b3447127f20d9903fe81a428f1336c3440121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffffb32b75cf1df78a196deb1f6ad968cf0f700f68be1acc09bfa43983462966963a000000006a47304402204f98dc42f53d2fc0f6f81fa90b70e0314518abbc98c330454b8402e067e64b0f022038a34d8179fdf5c40a6337f4a83ba45f6294c8b60cf6e829314bf8c33ced05af0121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffff93a0e1838d5f54bc95387eb902132bb9c9ceca8055f21f538d789fd7954d1f64360000006a473044022079ca74f6d961832c1a7bc707338809b65e5e45e68fd74fe9929bb8661fc3901302202102ea2e7aa22bdb7c812328d9b1c42429544c8a12d8ffc6de18c8c0e70552080121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffffd447616ffa92e26a87d20fb8a654f6f38d6385cecefe722618862b0fe340416f150000006a473044022038f08ffc28e07c7399de5076dfe2d309ce9e680b398af3263faadaf281ccf00e0220596e489a68399569c1f3125822e079c63769edec8c9ca5590d08e67ed8f4ae8c0121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffff5de2ee3334c219716ca93d718a0361d157d7070dacce7cf01e0d859766aa2480030000006a47304402204964646a3582c0f601c4f4164a71d812392facd05d6ba78954bbb9aec059b18302204cae9d6afb0f782c4fae040d0fb9f44d6f00d3636fc8732818e1d28ae46cf6460121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4fffffffff4e5a89ef14a1aa7b3f1bae64de6e190a59083c735ed1edc873071e583a004a1000000006b483045022100f6bc72aef7cf3ef7d716b2b191672d09ba26f9556b909ce8880ff15cc9ca244302205765cc48e34c32bd11ba4266e2098d8b71aaec7e3b6ba4e2dba293d68d6e38ee0121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffff078bfdcf979f864b401607693d2bf7c5df0b9ae1275183909fc29b0490b59ba9000000006b483045022100c905cda3f5fac4d02c7f69623e943ee7af8d5dc1eb6b4e4671b28b403ec5a3a7022062a610ec99296180e41179daea17063b702b81e82b2f67fd44c35481a814aa940121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffffb986644709add34b261b7b650f7b95e61d050a1d1587245644be305cd87bf3de000000006a473044022033b610ffa28afdaae4135eae375c1da7e7303ad3c2a74761db2f11b76b833d3002205190280708344cc681dae8c358ed840357fd10cb1083d9e05efbd942e1a3bb3b0121039a5023f31849aaa610b989373b5bd3bd27f53c7e5da76a65b575834c9983d5b4ffffffff02bdc50100000000001976a9144bb24d9fe0740a4ae020ea2fb831bbd79e867aff88ac60f20921000000001976a9144e7785c3c92fc08822ea54737b1bb93a18b5d17c88ac00000000 94b30d599b51f3549592590cd5659a98a7e4b200a30743f32a57a49e2c613511 01000000067b0d4ffef1d26e5b150e55197ca3e07c0195663536011d88652392f6e74b7325000000006a4730440220259091f30c2f4f535a090d606b74eae124a8d3d0f797296d7a976b23235a1a1b02201b8e0a19d07b76c1181496b36aec850fc5f586abcea62d6939de93e837780f6b012103589200af15f39797a0bd193ae408fe1f7445db371971d6d7a0131ee1510042c0fffffffff71da906b4951318bea661bfb683bef2eca9df2bde7aaf9ab322c242531a2338000000006a47304402200329a3fd44b72d138ddb0548295092eb63c7209c046127909755628508c9a89d022067316c7d8193d63390535b7535ac6b62e1437ca4ae6b164fe83b3bea49d607a501210250a8c2712aff3c925ee7dc42c259db9d372205e826e8bc77eff6126b56bcd238ffffffffbe9ce6e7ccf71b22f8623e9bda7aced0ea7bba37cda16e2fcfa6d2b36dbb2b45000000006a47304402201072f6557aa7f0e5f1d889e0d98cbee7cd3305e3a4b4a6d832adec10d29715d202205df9c62cff870edde7c0420ad36cfbbf3eb66eee7135e0e3a5b4f662122f58db012103589200af15f39797a0bd193ae408fe1f7445db371971d6d7a0131ee1510042c0ffffffff2be8ca84a60effb761dec32b5c1f667bedde394960776b70cd6ad35419746a8c010000006a473044022027861600d7552ff0e0843c4ff72ee0d138117b9bff3223b1e559b9f8b7e362b20220061f1459792610ef6a665051ff581380ba79bd24163bf30db6491d93e728812e012103589200af15f39797a0bd193ae408fe1f7445db371971d6d7a0131ee1510042c0ffffffff620b1bd506502430be823701b19802ffd473e8839d7c9b5b982a865a3cb6b4eb000000006b483045022100c37a3c431110ace0565c866abf3b95d6aee86c43f3681491292cb8f6f759fdd102200f657d5d147326c9bacafd881db822aaedfca36cba8e6b87b60d20e2760a012c0121034faa4d0ce73404cd8f6c172bda4069a464c86d00ea5513d6165b3f3b12263d6fffffffff72a2c6cfcbad000074b2a73cc6fc219745ec92b796e4e068d3928eccf2aa33fc000000006b483045022100dfb99ff05fa1308249163773339938f28daf655568294a23e643c16a4b875c1b022038937cd0b5dce8c0dab719b0c44da595ad79dab4c8012c64f6fd141ad5850ba101210268b22f61968baaaca03b017be0cdc8b7da2111964e9bac2a1f27e2f11f20667dffffffff0272620000000000001976a914751c753a2945da924cc32d805441ddd37e08fd7b88ac80bfab14000000001976a9142391db98b10f6d7572d2d911913f75881ddf484188ac00000000 4ab02be9300a07d1c78264814b797d289d7576e574a3b4b74ae4edc004fc2bfb 0100000002a3d5912c1eaa43b5004c3c74becef2fa0d3203ea4b18b833189aa8129b165f02010000006a47304402205afac11dc8f37aff2423f4a1e564ef050a083b3b2931207a440e3d85c7a38b9d02207a4e503edad6d03562bef104c528a845f7b7ecdda3bbceafc6deaf1e52e1015801210345eb44deb357b921470335c1f0eaffbf1309d30a0a13685c988698b975296aa5ffffffff1135612c9ea4572af34307a300b2e4a7989a65d50c59929554f3519b590db394010000006b483045022100bb67a0bf84b2902243a8a59678e2f620a263ee6ba554cb597473aaabe31612f1022047fb23ae760cc307e959f0eab86000f2da284f198527a6bb9e21838092b786f40121020cdeca8a315e43ba9ac503b722e98608f9151bc704fc3735d9b6f37a46b26851ffffffff02d044f211000000001976a9144c870d8c54077f3ec66912dc4d46ef326467128b88ac0046c323000000001976a914bbecf834e425b5155b82be0f2d92923b27b60ead88ac00000000 |
|
|
|
|
The blockchain does not create wallets nor does it assign addresses. It is just a ledger of the transactions.
If you use electrum to create an offline wallet, the wallet will generate a large random number and this is your master private key. It uses that to derive other large semi-random numbers which are private keys to in. Since everyone using Bitcoin has agreed to use certain rules, those random numbers become private keys which become valid Bitcoin addresses so long as it uses the same rules that every has agreed to.
When using an offline wallet, the offline wallet doesn't know about the blockchain and what outputs are available for it to spend. You must create a watching wallet which will then be transported to an online computer. That watching wallet knows about the addresses in your offline wallet but it is unable to actually spend the Bitcoins. Rather it just knows about the transactions and can create unsigned transactions with the proper inputs. That unsigned transaction is then moved to the offline wallet for signing and then back to the online wallet for broadcasting.
|
|
|
|
There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.
Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312) |
|
|
|
Is there no cross compiling? |
|
|
|
|
Show Posts
