 Show Posts
|
|
Pages: [1] 2 3 »
|
I'm getting fed up of various projects claiming to be open source when they aren't... I'm getting fed up with some people referring to open source licenses as open source. For God's sake, let "open source" mean open source. |
|
|
|
|
Hmm, not my experience at all. I just logged into Fidelity and was able to purchase FBTC just as easy as anything else.
Maybe you misunderstood my question. I want to purchase BTC ETF shares equivalent in value to an amount of BTC that I would send them from my private wallet, without selling my private wallet BTC first (thereby creating a taxable event). I would still be the owner (so no tax event) but the ETF issuer would now be the custodian.
|
|
|
|
|
Do any ETFs offer conversion from a private wallet to their ETF that is not taxed upon conversion?
|
|
|
|
Ahem... you appear to be correct. But only recently. It appears that Blockchain started recording this only a month ago, at block 660900, or thereabouts. As a side note of no consequence, during my attempt to find this transition I ran across a block for which I could not determine whether Blockchain was recording or not, https://www.blockchain.com/btc/block/660500. The block consists only of a coinbase. :/ And on another attempt, when surfing to a page of transactions included in a block by modifying the URL, I just coincidentally choose the last page of 211 exactly, on my first try.  |
|
|
|
the closest I can think of would be the "received time" shown for a transaction on blockchain.com The time listed there is the timestamp of the block. Bitcoin core seems to store the time it first saw the transaction... It does appear that Bitcoin Core records the sent time of a transaction, which is great to know. Thank you. For the transactions for which I am currently looking for sent times I was using Electrum, unfortunately. |
|
|
|
... you should be able to see the time associated with it ...
There is no mention of a mempool or of a time associated with one. ... you should be able to see ... the block height when it was signed.
How do I determine the time that the transaction was sent to the mempool from the block height? |
|
|
|
|
I would like to know the time a confirmed transaction was sent to the mempool. Does Electrum store this information? Or is there an online service that has this information available?
|
|
|
|
Now that I've figured out how to pair my MEW to the EOS blockchain. Can I keep transferring EOS to my MEW or was that pairing only done for the tokens that I stored in my MEW at the time I did the pairing?
Per the Exodus article you linked to above, "You will only have to perform the registration process once. Any additional EOS tokens sent to your wallet after you complete the registration process will also be registered." |
|
|
|
Noitev, you are not very good at accounts and passwords, are you?: I lost my electrum password.
|
|
|
|
How can Trezor support not allow a return if the device does not work with your computer? Any other electronic device I have ever ordered was returnable if the device did not work with my computer. |
|
|
|
Or are you talking about SegWit blocks stored by a Legacy Node?
This is it. If you are asking about SegWit blocks stored by a Legacy Node, then those nodes are fooled into thinking that bitcoins sent to a SegWit address are sent to a "ANYONE CAN SPEND" output. Therefore, when they try to validate the blocks that spend those bitcoins, they are unable to tell the difference between a block where those bitcoins are validly spent or a block where they are invalidly spent. In other words, a Legacy Node is unable to fully validate a block that has transactions spending bitcoins that were previously received at a SegWit address. Instead, it must trust that those blocks have been validated by a SegWit node.
This is what I was looking for. Thanks. If you are asking about SegWit blocks stored by a Legacy Node, then I've already explained that the Legacy Node can't tell the difference between a valid transaction that spends bitcoins which were previously received at a SegWit address and an invalid transaction that spends bitcoins which were previously received at a SegWit address. The Legacy Node must trust that the block has already been validated by a SegWit node.
More confirmation. Good stuff. Except that we would miss out on all the benefits that SegWit provides. SegWit was not intended to be a method of significantly increasing throughput. It was intended to fix some issues with bitcoin transactions (such as maleability), and to make other transaction types easier or possible.
Ah, yes, true dat. Thanks again. |
|
|
|
Thanks for your reply and help, Xynerise. My question was because I read this: When serialized to a Legacy node, they will be 400 bytes, 300 bytes and 500 bytes respectively (tx size without witness data). When serialized to a Segwit node, they will be 800 bytes, 1100 bytes and 500 bytes respectively.
If the witness data isn't included in segwit transactions then how do you validate a transaction without the signature?  The same way you validate that same transaction when it's included in legacy blocks? Or do legacy blocks need not validate segwit transactions? If not, why not? As soon as we discovered we don't need witness data in legacy blocks why not simply cut them out? So we agree that, on average, the block size will increase approximately 2x in Segwit. With that 2x size increase we will also get 2x throughput? If so, we could have done just as well simply increasing block size without Segwit. |
|
|
|
|
My understanding is that Segwit transactions that are included in legacy BTC blocks do not contain witness data. Why then include witness data in Segwit transactions that are included in Segwit blocks? It seems like we get 2x transaction throughput for 4x block size, or maybe 2x block size on average. So why even bother with Segwit?
|
|
|
|
|
Sorry for the repetition, but can I use bech32 addresses in Electrum with Ledger Nano S? If so, how?
|
|
|
|
|
Regarding AML bitcoin, how many tokens were sold during phase 1? And how many and at what price in the private sale?
Support said they could divulge this info due to SEC regulations, but I have not encountered this issue with other ICOs.
|
|
|
|
|
Thanks for the advice, go4crypto. I'll try it out and let you know how it goes.
|
|
|
|
|
A transaction used 4,000,000 limit, 2 gwei, and claim (instead of claimall), and after 18 hours it still hadn't been processed.
Another transaction successfully used 1 Gwei and only 81,253 limit.
|
|
|
|
|
How much gas do I need to supply to claimall EOS?
|
|
|
|
...you have to add a leading 0 to the amount.
This post should be listed at the top. It is a correct solution. Now WEX.com still has this issue. |
|
|
|
|
