|
SITE BACK UP. SHOULD WORK NOW. ALL PREVIOUS TOKENS ARE NOW INVALID.
|
|
|
|
Mine says "Please wait. You are number 25 in the queue". I waited for about 10 minutes and seem like its not moving. why does it have to put us on queue?
It looks like there is a bug in my code that is crashing the main calculation thread. I will take the server down for a few hours while I figure this out. SERVER GOING DOWN FOR MAINTENANCE |
|
|
|
I think I did not explained myself properly.
I'm thinking about different blockchain implementations.
Imagine that I'm creating a private specialized network that will process complex contracts.
Would there be any way that I could store contratcs outside the blockchain and just reference them in the transactions?
Of course. You can do anything with your own blockchain but such a thing doesn't exist in the bitcoin blockchain. |
|
|
|
About item 4, it still looks suboptimal to me. Imagine that I have a firm where in order to spend the payment from customers I also have to get the signatures from at least 1 of 2 other partners. My script would look like: 2 <My PubKey> <Partner 1's PubKey> <Partner 2's PubKey> 3 OP_CHECKMULTISIG So, for every incoming payments that I'd like to spend, my scriptSig would have to be bloated with the script above plus 2 signatures <sig1> <sig2>. Imagine that I'll have thousands of these transactions, this would be bloating the blockchain, probably decreasing the processing capabilities of the network. I was wondering: is there any way of mantaining these scripts as "accounts" in "script wallets" and not storing it inside the blockchain? When there is need for validation, I could simply retrieve this script form the "wallet" and check the transaction. How would it be possible? It's all the same, both will still end up in the blockchain one way or another. The difference is that with bare multisig, nodes will have to maintain that extra data in a UTXO database instead of not at all in a database when it is in the blockchain. |
|
|
|
when you say "receive" but not spend, it is received and unverifiable and unspendable, right?
In essence, yes. is it just me, or does it seem like calling this a softfork might be technically accurate, the market confusion and incompatibility it will cause is pretty much like a hardfork
Yeah, pretty much. Although it still allows for the old type transactions so old wallets will still work. IIRC segwit was originally proposed as a hard fork. |
|
|
|
wow, that's a LOT of changes... practically speaking, will segwit tx work for sending to an old wallet or do both sides need to run it for it to be spendable. it seems that would be the case. if so, doesnt that create a lot of problems along the lines of "i sent you this txid, but you need this wtxid to be able to spend it, oh and the new updated wallet that supports segwit that isnt available yet from your vendor" The txid of a segwit transaction will be the same segwit or not since the signatures are not part of the transaction. Unupgraded users will be able to receive but not spend from validate segwit transactions fully. They can spend from segwit transactions because the output will still have to be a p2pkh output to non-upgraded wallets. Edit: Fix error where I said that segwit txs could not be spent from. |
|
|
|
Doesn't the segregated witness transaction malleability fix pave the way for the lightning network? They are not competing solutions, rather one enables the other.
Yes, part of what segwit does is make a part of the lightning network easier to do. None of these solutions are competing with each other, they can all coexist. It is possible to have all of these solutions at the same time, and I think that that will happen at some point in the future. And also, from what I understand, the blocksize reduction achieved by culling unlock scripts from transactions that segregated wintess brings will be insignificant compared to effect of the lightning network.
Probably. Segwit has an effective increase as a doubling of the maximum block size. AFAIK the lightning network, and sidechains as well, could in theory go infinitely. |
|
|
|
|
The current network consensus is to have a maximum block size of 1 Mb. This means that 1 Mb of transactions can be stored in one block. Transactions have a data size, usually between 200 and 500 bytes and this is what takes up space in a block.
The issue that some people have with 1 Mb blocks is that at some point, there will be so many transactions that all blocks will be reaching the maximum number of transactions that they can contain. The idea is that increasing the maximum block size will allow for more transactions to be included in a block. This would then allow more transactions to confirm in one block and, in theory, keep fees low as long as there is space in blocks for transactions.
Additionally, when blocks become full, there is an idea that this will create a fee market. This essentially means that fees will increase as people have "bidding wars" with their fees to have their transactions included in a block since there would not be enough block space for all of the unconfirmed transactions. This would drive up fees and thus earn more income for miners but could potentially drive away users as the fees become too high.
Larger blocks have their drawbacks, as do smaller blocks. Larger blocks require more data to be transferred, and as blocks grow larger, the bandwidth requirement increases. There is also a verification slowdown that is caused by large blocks. The time required to verify a block grows exponentially in relation to the block size. These factors can lead to slowdowns in the propagation of blocks and therefore increase the orphan rate of miners. This additional bandwidth requirement can also make it difficult for more full nodes and miners to come online.
Smaller blocks, on the other hand, can restrict the network capacity. They can prevent many transactions from being confirmed if there are too many transactions in the pool of unconfirmed transactions. This can cause delays for transaction confirmation.
Increasing the maximum block size is just one of the proposed solutions for increasing the number of transactions that the Bitcoin network can process. Alternatives include the lightning network, sidechains, and segregated witness among a variety of other proposals.
Bitcoin Core, Bitcoin Classic, and Bitcoin XT are various clients that implement slightly different consensus rules when it comes to the block size limit, which is also why some people consider Bitcoin Classic and Bitcoin XT as altcoins since Bitcoin Core is considered the reference implementation.
Bitcoin Core proposes to use segregated witness. Segregated witness is a solution to transaction malleability which has a side effect of decreasing the size of a transaction and thus increasing the number of transactions which can be put into a block. This also solves the exponential verification time problem and makes it linear.
Bitcoin Classic is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 2 Mb.
Bitcoin XT is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 8 Mb and to constantly increase at a rate which doubles the maximum every two years until a final size of 8 Gb is reached.
Please note that this post is supposed to be neutral and informational. If there is anything wrong about the information, please let me know and I will fix it.
Edit: typos
|
|
|
|
It's me again...
*knightdk shudders and curses under his breath*
We're so close. I can feel it in my bones!
Now I'm getting this message:
"Please wait for your previous request to finish and try again"
Try again. I rebooted the server. It should work now.
ALL PREVIOUS TOKENS WILL NO LONGER WORK!!!!! |
|
|
|
Compressed keys? (The private ones that begin with K or L instead of 5.)
Not yet. It is on the todo list. |
|
|
|
|
What you just proposed is basically sidechains, something already proposed and being worked on. Google it to find out more on how it works.
|
|
|
|
Im using Bitcoin-Qt version 0.11.2.
bootstrap.dat is unpacked, sorry if i got you confused there. The problem is bitcoin-qt acts as if it wasn't there.
First of all, after 0.10, the bootstrap.dat will not be faster to sync. Bitcoin core does recognize the bootstrap but it needs to index all of it so it will appear as if it is syncing from scratch. |
|
|
|
@knightdk, i am unable to find the box to enter UID , i have cross checked all settings and my script tab is enabled in chrome , i have even tried opening the site in different browsers like opera and Firefox but still text-box is not appearing.
Yes the UID box is not appearing so I am unable to see my previous tokens (which i generated within 1 week) Please remove this bug. Yes, I am working on it. I am currently unable to access my server since I am on mobile right now so it may be a few hours until it gets fixed. The tokens no longer work since the server had to be rebooted and that cleared the tokens. Edit: should be fixed now |
|
|
|
Same issue here, tried to open but no space to enter the UID
I tried to clear cache ctrl+shift+delete but same thing no space to enter UID
Is the browser have anything to do with it? I'm using chrome
Edit: Tried using Mozilla, same thing, no space to enter the UID
I don't have that problem so I'm not sure what is wrong. Do you have JavaScript enabled? |
|
|
|
Great! Well thanks a lot for your efforts to fix it for little old me. I'm sure it's going to help someone else out there too haha. Your text box does seem to be missing at this point.
Seems like the update solved the problems I had regarding the account of JumperX aswell. Thanks for the quick fix! Were you able to type in your user ID? I don't see the text box anymore. It sounds like trinaldaois having the same issue. Try clearing your browser cache. |
|
|
|
Well for me it is even worse: Displayed: 13927
Show posts: 14062
Interesting discovery; I wonder why this is. I've notified theymos, however it might take time until he notices this. This is caused due to some posts not being counted (e.g. Moved threads). Take CyrusV for example, the difference for him is over 1000 due to many such threads. Oh, that makes sense now. Chris! has two posts for Moved threads so that would explain the discrepancy there. I still don't understand why a lot of people have 1 less post in the show posts than in the count though since I have seen it in many profiles. |
|
|
|
I'm willing to bet that the forum simply doesn't update post count in real time.
It probably doesn't but it is still very fast. Edit: Nope, it is definitely in real time. I refreshed my profile right after I made this post and the count went up by 1. |
|
|
|
Thanks for the quick replies.
Pardon me as I've not been able to follow this thread for a couple of weeks now but is there already an official release of 0.94? If so, where can I get it?
Not yet, just a testing release. The latest testing release is available at https://github.com/goatpig/BitcoinArmory/releases/tag/0.93.99.1With Windows, I'm aware that the same executable can be used to install both online and offline wallets. With Linux (I have Mint), I think the offline wallet installation requires a separate "offline package", IIRC. Would it still be the same installation procedures with 0.94?
When the official release comes out, it should all be the same installation procedure. |
|
|
|
My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?
These versions will still be compatible however you should consider upgrading. 0.94 has a new database structure which reduces the databases by a massive amount (from 60+ Gb to a 300 Mb IIRC). |
|
|
|
|
Show Posts
