Bitcoin Core - Desktop - Windows - Wählen Sie Ihre Wallet ...
v5.3.7 is out on iOS and Android
Electrum seed for Segwit and Legacy
Improved Entropy generation module
Support for Deeplinks (:bluewallet)
Improved Storage delete/not-delete
Improved RBF/CPFP screen
Fee suggestion selection
Electrum seed recovery bug
Allow RBF/CPFP view to be scrolled on small devices
Biometrics switch value
Prevent possible crash on LN invoice screen
This release feature contributions from the fantastic: junderwood4649 / tankredhase / bordalix / marcosrdz / overtorment / nvcoelho With fees getting high we improved our RBF/CPFP screens, that allow you to bump or cancel transactions. We also improved our fee calculations algorithm. Try them out, it is an empowering feature on times like this. replace by fee Still with us?! Building a Bitcoin wallet is hard, specially when you want to fight against blockchain/info and bitcoincom. How can you help? Leave us a review on the app stores. It really helps! Is that simple :) Onboarding one user a day. Keep building! 💙👊 bluewallet.io
Another Quarter, Another Release! The Groestlcoin production factory has been working overtime as always in order to deliver even more tech to push Groestlcoin mainstream when the time comes. There have been many new fantastic wallets and exchanges added to Groestlcoins repertoire over the past 3 months so we will re-cap these before moving on to what is new today.
Groestlcoin added to SatWallet – A 3-in-1 service. Multicurrency wallet, exchange and soon a debit card!
ChangeHero announced a week of 0% commission for Groestlcoin trades.
Added to BC Bitcoin cryptocurrency exchange, offering 8 fiat pairs!
Added to Chameleon Pay mobile wallet for Android and iOS!
Added to the Okex' strategic partners cryptocurrency exchange; CoinAll! Offering BTC and ETH pairs! With a 21,5000 GRS Giveaway!
Added to Spark Card! Our second MasterCard for Groestlcoin! Provided by Pungoio, powered by TarjetaSpark and issued by Mastercard!
Added to Swirlpay! A decentralised peer-to-peer payment gateway.
Added to Archos Safe-T Mini hardware wallet! Built around encrypted Chipset memory.
Added to Agama Wallet – A multi-asset encrypted wallet for iOS, Android, Windows, Mac OS and Linux from Komodo.
Added to Mr Coin exchange, with 2 fiat pairs (EUR and HUF)
Added to CryptoFacil Exchange – An exchange powered by Bittrex and is a fiat gateway. Leaving you with the ability to buy GRS with Visa and Mastercard.
Added to Bits Game – A gambling service with 2 'PvP' games
Added to Boost X Change Cryptocurrency exchange!
Added to Sucon's Suworld Korean cryptocurrency exchange!
Added to DCXinsta cryptocurrency exchange and swap service with Fiat pairings.
Added to DCXtrade, an Indian cryptocurrency exchange with BTC and ETH pairings.
Added a fiat KRW pairing on Huobi Korea Cryptocurrency Exchange!
Added to AirGap wallet, allowing you to securely store your GRS on an offline device.
Added as a payment method on hodlhodl, allowing you to make global trades without KYC/AML.
Added to TrustWallet cryptocurrency wallet for iOS and Android
The existing Magnum wallet adds SegWit support for the wallet! Allowing SegWit addresses to be used and created from within the wallet.
Added to CycleBit – Who provide POS Terminals that accept GRS payments anywhere, in-store and online. 130 coffee houses in Spain already accept GRS using Cyclebit POS terminals!
Added to Bitinka Cryptocurrency exchange! The #1 exchange in Latin America with 5 fiat and cryptocurrency pairs!
Added to Atomic wallet, a non-custodial cryptocurrency wallet with encrypted private keys and 40,000 monthly users.
Added to NoMiddleMan cryptocurrency payment gateway, offering no usernames, no registration, no KYC, no fees. Completely free to use!
Added to Blockchair! An advanced data analysis tool, mempool monitor and block explorer!
Added to SecuX V20, SecuX W20 and SecuX W10 hardware wallets!
Re-forged: Groestlcoin Samourai
Groestlcoin Samourai is a wallet for the streets. A modern Groestlcoin wallet hand-forged to keep your transactions private, your identity masked, and your funds secure. Its main advantages are its extreme portability and is the most secure Groestlcoin mobile HD wallet. We've built a wallet that Groestlcoin deserves. If you are looking for a wallet that Silicon Valley will never build, the regulators will never allow, and the VC's will never invest in, this is the perfect wallet for you. ![Groestlcoin Samourai Release Video](http://img.youtube.com/vi/i3WU8Tde8XQ/0.jpg)
Head over to the Groestlcoin Samourai Release Page here for the full release announcement.
Groestlimage turns any file into a mnemonic phrase allowing users to generate Groestlcoin private keys and addresses based on the data URI of the provided file. A picture is worth a thousand Groestls.
Turn any image, document or audio file into a BIP39 mnemonic phrase
Groestlcoin Core Config Generator is a simple GUI to configure the groestlcoin.conf file – A developers dream tool! Each configuration option is available via the user interface, grouped by what attributes they affect. For ease of getting started with a new configuration, a variety of preset "node classes" are available on the right-hand-side of the screen. Selecting a preset will load our recommended base configuration for a node fitting that description, at which point you can then tune the configuration at the single option level.
Choose between Mining, Non-Standard Ports, Low Bandwidth, Pruned, Raspberry Pi, Tor, Testnet, Regtest, Non-Syncing and Lightning Éclair presets.
Groestlcoin Simple Push TX is a server to push Groestlcoin transactions via SMS. Now everybody can send new transactions via SMS if the Internet is not usable (i.e. blocked by government entities or becomes otherwise unavailable).
Ability to push either Base64 or Hex-Encoded Raw Transactions via SMS.
Send SMS transactions to PushTX through the number +32460224477 (+32460224GRS)
Electrum-GRS is Groestlcoins #1 thin-client for Windows, MacOS, Linux and Android, based on a client-server protocol. Supporting multi-sig wallets without the bloat of downloading the entire blockchain.
New Features (Universal)
Electrum Protocol: The client's "User Agent" has been changed from "3.3.6" to "electrum/3.3.6". Other libraries connecting to servers can consider not "spoofing" to be Electrum
Added CoinGecko.com fiat rate provider. Changed default provider to CoinGecko.com
Minor bugfixes and usability improvements.
New Features (Windows, MacOS, Linux)
Fix Crash during 2FA wallet creation
Fix Synchroniser so that it does not keep resubscribing to addresses of already closed wallets.
Fix removing addresses/keys from imported wallets
The logging system has been overhauled. Logs can now also optionally be written to disk, disabled by default.
Fix a bug in the synchroniser where client could get stuck. Also show the progress of history sync in the GUI.
Fix Revealer in Windows and MacOS binaries
Ledger Nano X is now recognised, supporting mainnet and testnet
KeepKey is now recognised and supports mainnet and testnet
Device was not getting detected using Windows binary
Support Firmware 6.0.0+
Implement "Seedless" mode
Coin Control in QT – Implemented freezing individual UTXOs in addition to freezing addresses
Fix CPFP – The fees already paid by the parent were not included in the calculation, so it was always overestimated.
Testnet – There is now a warning when the client is started in testnet mode as there were several reports of users getting scammed through social engineering.
CoinChooser – Performance of creating transactions has been improved significantly for larger wallets.
Importing/Sweeping WIF keys: Stricter checks
Several other minor bugfixes and usability improvements.
New Features (Android)
Fix rare crash when changing exchange rate settings
Fix bug with local transactions
Allow selecting Fiat Rate providers without historical data
Remember that you can use CPFP or RBF to get your transactions confirmed faster.
All three solutions below, attempt to solve the same problem, the issue of stuck transactions. Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have created a malformed transaction (for example, accidentally setting 0 fees) that isn't acceptable or mine-able for various reasons, and it's desirable for them to be able to reissue a fixed transaction. This is exacerbated by the undefined memory pool behavior of nodes with respect to expiring out old transactions, and not having a clear rule as to when it's safe to attempt another spend. 1) Child-Pays-For-Parent (CPFP) The Child-Pays-For-Parent approach allows the fees of a transaction's child (the transaction that spends the outputs of the stuck transaction) to also pay for the parent transaction. This allows a merchant to spend the "broken" transaction they received like any other transaction, and the system should return to a consistent state. The benefit of Child-Pays-For-Parent is that it solves the problem in a way that doesn't fundamentally change the mechanics for how a transaction is selected and kept (most notably, the first-seen memory pool behavior). In my opinion, this makes this solution the most intuitive. However, the difficulty with Child-Pays-For-Parent is in the implementation. There are some required changes to the propagation of transactions that are required to make this work properly (since just broadcasting a valid child will cause other nodes to consider the transaction as orphaned, without the context of the parent). 2) Replace-By-Fee (RBF) Replace-by-fee attempts to address the problem by changing the fundamental rule for accepting and keeping transactions, the "first-seen" rule. In this system, a transaction with higher fees can spend already spent inputs (that have not yet been confirmed in a block), and will replace that transaction in the memory pool. The benefit of this system is that it changes the fundamental transaction selection rule but does not require changes to the way fees are calculated. The downside is that this represents a significant shift in terms of expected memory pool behavior. In my opinion, this makes transactions less predictable; the first-seen rule is straightforward, predictable, and easy to understand and implement. Additionally, it breaks any functionality that relies on the predictability of unconfirmed transactions by making it trivial to issue double spends. (Double spending a first seen transaction requires a combination of moderate network and computing resources, some decent know-how, and some luck. Double spending in a replace-by-fee world requires none of the above.) 3) First-Seen-Safe Replace-By-Fee (FSS RBF) This one attempts to make RBF compatible with first-seen memory pool implementations by requiring that the outputs from the original transaction be maintained by subsequent respends. The benefits are that in some situations, first-seen behavior can be relied upon. A transaction sending x BTC to a merchant cannot revoke that. In practice, however, this protection is pretty weak. It trivially breaks transactions that spend other unconfirmed transactions by allowing the first transaction in the chain to be replaced, invalidating future outputs. This means that the burden for double spending an unconfirmed transaction becomes only slightly higher than in standard replace-by-fee. It does, theoretically, allow one to accept an unconfirmed transaction that spends a confirmed output with similar protections as the typical first-seen behavior. It is impossible to talk about this without touching on the politics, though. The reason this is so contentious is that it involves a political change that breaks many systems that rely on first-seen memory pool behavior. The proponents of the change believe that since unconfirmed transactions are not subject to the same cryptographic protections as confirmed transactions, they should be pushed out of the ecosystem and tools that facilitate this should be adopted. The people who oppose this change believe that unconfirmed transactions represent an acceptable risk as with everything in Bitcoin (remember, Bitcoin requires a majority of honest miners, for example), and that breaking something many people rely on unnecessarily is a net negative. https://bitcoin.stackexchange.com/questions/38320/can-someone-outline-the-full-pros-cons-of-the-various-replace-by-fee-proposals EDIT: More info on this sticky
I'll briefly summarize before providing some commentary of my own, including transformation of the proposed mechanism into a relatively simple soft-fork. The article points out that bitcoin's auction model for transaction fees / inclusion in a block is broken in the sense that it does not achieve maximum clearing price* and to prevent strategic bidding behavior. (* Maximum clearing price meaning highest fee the user is willing to pay for the amount of time they had to wait. In other words, miner income. While this is a common requirement of academic work on auction protocols, it's not obvious that it provides intrinsic benefit to bitcoin for miners to extract from users the maximum amount of fee the market is willing to support. However strategic bidding behavior (e.g. RBF and CPFP) does have real network and usability costs, which a more "correct" auction model would reduce in some use cases.) Bitcoin is a "pay your bid" auction, where the user makes strategic calculations to determine what bid (=fee) is likely to get accepted within the window of time in which they want confirmation. This bid can then be adjusted through some combination of RBF or CPFP. The authors suggest moving to a "pay lowest winning bid" model where all transactions pay only the smallest fee rate paid by any transaction in the block, for which the winning strategy is to bid the maximum amount you are willing to pay to get the transaction confirmed:
Users can then simply set their bids truthfully to exactly the amount they are willing to pay to transact, and do not need to utilize fee estimate mechanisms, do not resort to bid shading and do not need to adjust transaction fees (via replace-by-fee mechanisms) if the mempool grows.
Unlike other proposed fixes to the fee model, this is not trivially broken by paying the miner out of band. If you pay out of band fee instead of regular fee, then your transaction cannot be included with other regular fee paying transactions without the miner giving up all regular fee income. Any transaction paying less fee in-band than the otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate difference fee to make up for that lost income. So out of band fee is only realistically considered when it pays on top of a regular feerate paying transaction that would have been included in the block anyway. And what would be the point of that? As an original contribution, I would like to note that something strongly resembling this proposal could be soft-forked in very easily. The shortest explanation is:
For scriptPubKey outputs of the form "", where the pushed data evaluates as true, a consensus rule is added that the coinbase must pay any fee in excess of the minimum fee rate for the block to the push value, which is a scriptPubKey.
Beyond fixing the perceived problems of bitcoin's fee auction model leading to costly strategic behavior (whether that is a problem is a topic open to debate!), this would have the additional benefits of:
1. Allowing pre-signed transactions, of payment channel close-out for example, to provide sufficient fee for confirmation without knowledge of future rates or overpaying or trusting a wallet to be online to provide CPFP fee updates. 2. Allowing explicit fees in multi-party transaction creation protocols where final transaction sizes are not known prior to signing by one or more of the parties, while again not overpaying or trusting on CPFP, etc. 3. Allowing applications with expensive network access to pay reasonable fees for quick confirmation, without overpaying or querying a trusted fee estimator. Blockstream Satellite helps here, but rebateable fees provides an alternative option when full block feeds are not available for whatever reason.
Using a fee rebate would carry a marginal cost of 70-100 vbytes per instance. This makes it a rather expensive feature, and therefore in my own estimation not something that is likely to be used by most transactions today. However the cost is less than CPFP, and so I expect that it would be a heavily used feature in things like payment channel refund and uncooperative close-out transactions. Here is a more worked out proposal, suitable for critiquing:
A transaction is allowed to specify an Implicit Fee, as usual, as well as one or more explicit Rebateable Fees. A rebateable fee is an ouput with a scriptPubKey that consists of a single, minimal, nonzero push of up to 42 bytes. Note that this is an always-true script that requires no signature to spend.
The Fee Rate of a transaction is a fractional number equal to the combined implicit and rebateable fee divided by the size/weight of the transaction. (A nontrivial complication of this, which I will punt on for the moment, is how to group transactions for fee rate calculation such that CPFP doesn't bring down the minimum fee rate of the block, but to do so with rules that are both simple, because this is consensus code; and fair, so as to prevent unintended use of a rebate fee by children or siblings.)
The smallest fee rate of any non-coinbase transaction (or transaction group) is the Marginal Fee Rate for the block and is included in the witness for the block.
The verifier checks that each transaction or transaction grouping provides a fee greater than or equal to the threshold fee rate, and at least one is exactly equal to the marginal rate (which proves the marginal rate is the minimum for the block).
This establishes the marginal fee rate, which alternatively expressed is epsilon less than the fee rate that would have been required to get into the block, assuming there was sufficient space.
A per-block Dust Threshold is calculated using the marginal fee rate and reasonable assumptions about transaction size.
For each transaction (or transaction group), the Required Fee is calculated to be the marginal fee rate times the size/weight of the transaction. Implicit fee is applied towards this required fee and added to the Miner's Fee Tally. Any excess implicit fee remaining is added to the Implicit Fee Tally.
For each transaction (group), the rebateable fees contribute proportionally towards towards meeting the remaining marginal fee requirement, if the implicit fee failed to do so. Of what's left, one of two things can happen based on how much is remaining: A. If greater than or equal to the dust threshold is remaining in
a specific rebateable fee, a requirement is added that an output be provided in the coinbase paying the remaining fee to a scriptPubKey equal to the push value (see #1 above). (With due consideration for what happens if a script is reused in multiple explicit fees, of course.)
B. Otherwise, add remaining dust to the implicit fee tally.
For the very last transaction in the block, the miner builds a transaction claiming ALL of these explicit fees, and with a single zero-valued null/data output, thereby forwarding the fees on to the coinbase, as far as old clients are concerned. This is only concerns consensus in that this final transaction does not change any of the previously mentioned tallies. (Aside: the zero-valued output is merely required because all transactions must have at least one output. It does however make a great location to put commitments for extensions to the block header, as being on the right-most path of the Merkle tree can mean shorter proofs.)
The miner is allowed to claim subsidy + the miner's fee tally + the explicit fee tally for themselves in the coinbase. The coinbase is also required to contain all rebated fees above the dust threshold.
In summary, all transactions have the same actual fee rate equal to the minimum fee rate that went into the creation of the block, which is basically the marginal fee rate for transaction inclusion. A variant of this proposal is that instead of giving the implicit fee tally to the miner (the excess non-rebateable fees beyond the required minimum), it is carried forward from block to block in the final transaction and the miner is allowed to claim some average of past fees, thereby smoothing out fees or providing some other incentive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: Message signed with OpenPGP URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/8d6e3b63/attachment.sig original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Septembe015093.html
Extension block proposal by Jeffrey et al | Luke Dashjr | Apr 04 2017
Luke Dashjr on Apr 04 2017: Recently there has been some discussion of an apparent work-in-progress extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps it is still in pre-draft stages and not quite ready for review, but in light of public interest, I think it is appropriate to open it to discussion, and toward this end, I have reviewed the current revision. For reference, the WIP proposal itself is here:
==Overall analysis & comparison== This is a relatively complicated proposal, creating a lot of additional technical debt and complexity in comparison to both BIP 141 and hardforks. It offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to consider at face value. In fact, it fits much better the inaccurate criticisms made by segwit detractors against BIP 141. That being said, this proposal is very interesting in construction and is for the most part technically sound. While ill-fit to merely making blocks larger, it may be an ideal fit for fundamentally different block designs such as Rootstock and MimbleWimble in absence of decentralised non-integrated sidechains (extension blocks are fundamentally sidechains tied into Bitcoin directly). ==Fundamental problem== Extension blocks are a risk of creating two classes of "full nodes": those which verify the full block (and are therefore truly full nodes), and those which only verify the "base" block. However, because the extension is consensus-critical, the latter are in fact not full nodes at all, and are left insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is of course true of a softfork as well, but softforks are intentionally designed such that all nodes are capable of trivially upgrading, and there is no expectation for anyone to run with pre-softfork rules. In general, hardforks can provide the same benefits of an extension block, but without the false expectation and pointless complexity. ==Other problems & questions==
These outpoints may not be spent inside the mempool (they must be redeemed
from the next resolution txid in reality). This breaks the ability to spend unconfirmed funds in the same block (as is required for CPFP). The extension block's transaction count is not cryptographically committed-to anywhere. (This is an outstanding bug in Bitcoin today, but impractical to exploit in practice; however, exploiting it in an extension block may not be as impractical, and it should be fixed given the opportunity.)
The merkle root is to be calculated as a merkle tree with all extension
block txids and wtxids as the leaves. This needs to elaborate how the merkle tree is constructed. Are all the txids followed by all the wtxids (tx hashes)? Are they alternated? Are txid and wtxid trees built independently and merged at the tip?
Output script code aside from witness programs, p2pkh or p2sh is considered
invalid in extension blocks. Why? This prevents extblock users from sending to bare multisig or other various possible destinations. (While static address forms do not exist for other types, they can all be used by the payment protocol.) Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create unprovably-unspendable UTXOs. Is that intentional?
The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue as BIP141, but even more extreme since it is planned to be used for future size increases.
Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not just say "8 points"?
Witness script hash v0 shall be worth the number of accurately counted
sigops in the redeem script, multiplied by a factor of 8. Please define "accurately counted" here. Is this using BIP16 static counting, or accurately counting sigops during execution?
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is worth 1 additional point. Is the size rounded up or down? If down, 72-byte scripts will carry 0 points...) ==Trivial & process== BIPs must be in MediaWiki format, not Markdown. They should be submitted for discussion to the bitcoin-dev mailing list, not social media and news.
This specification defines a method of increasing bitcoin transaction
throughput without altering any existing consensus rules. This is inaccurate. Even softforks alter consensus rules.
Bitcoin retargetting ensures that the time in between mined blocks will be
roughly 10 minutes. It is not possible to change this rule. There has been great debate regarding other ways of increasing transaction throughput, with no proposed consensus-layer solutions that have proven themselves to be particularly safe. Block time seems entirely unrelated to this spec. Motivation is unclear.
Extension blocks leverage several features of BIP141, BIP143, and BIP144 for
transaction opt-in, serialization, verification, and network services, and as such, extension block activation entails BIP141 activation. As stated in the next paragraph, the rules in BIP 141 are fundamentally incompatible with this one, so saying BIP 141 is activated is confusingly incorrect.
This specification should be considered an extension and modification to
these BIPs. Extension blocks are not compatible with BIP141 in its current form, and will require a few minor additional rules. Extension blocks should be compatible with BIP 141, there doesn’t appear to be any justification for not making them compatible.
This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would expect. The UTXO set behaves fundamentally different to old nodes with this proposal, albeit in a mostly compatible manner.
Note that canonical blocks containing entering outputs MUST contain an
extension block commitment (all zeroes if nothing is present in the extension block). Please explain why in Rationale.
Coinbase outputs MUST NOT contain witness programs, as they cannot be
sweeped by the resolution transaction due to previously existing consensus rules. Seems like an annoying technical debt. I wonder if it can be avoided.
The genesis resolution transaction MAY also include a 1-100 byte pushdata in
the first input script, allowing the miner of the genesis resolution to add a special message. The pushdata MUST be castable to a true boolean. Why? Unlike the coinbase, this seems to create additional technical debt with no apparent purpose. Better to just have a consensus rule every input must be null.
The resolution transaction's version MUST be set to the uint32 max (`232 -
1`). Transaction versions are signed, so I assume this is actually simply -1. (While signed transaction versions seemed silly to me, using it for special cases like this actually makes sense.)
Exiting the extension block
Should specify that spending such an exit must use the resolution txid, not the extblock's txid.
On the policy layer, transaction fees may be calculated by transaction cost
as well as additional size/legacy-sigops added to the canonical block due to entering or exiting outputs. BIPs should not specify policy at all. Perhaps prefix "For the avoidance of doubt:" to be clear that miners may perform any fee logic they like.
Transactions within the extended transaction vector MAY include a witness
vector using BIP141 transaction serialization. Since extblock transactions are all required to be segwit, why wouldn't this be mandatory?
BIP141's nested P2SH feature is no longer available, and no longer a
consensus rule. Note this makes adoption slower: wallets cannot use the extblock until the economy has updated to support segwit-native addresses.
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is worth 1 additional point. Please explain why 73 bytes in Rationale.
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
A consensus dust threshold is now enforced within the extension block.
If the second highest transaction version bit (30th bit) is set to to 1
within an extension block transaction, an extra 700-bytes is reserved on the transaction space used up in the block. Why wouldn't users set this on all transactions?
default_witness_commitment has been renamed to
default_extension_commitment and includes the extension block commitment script. default_witness_commitment was never part of the GBT spec. At least describe what this new key is.
Deployment name: extblk (appears as !extblk in GBT).
Should be just extblk if backward compatibility is supported (and !extblk when not).
The "deactivation" deployment'...[message truncated here by reddit bot]...
Bitcoin noob here, go easy. 3 days ago I sent ~0.046 from my electrum wallet to my coinbase account with the intention of cashing out and moving my investment to other cryptos. Being a noob, I assumed electrum's automatic fee would be enough, and I sent the transition. It showed up in my electrum history with a "low fee" warning tag. Shortly thereafter, the TX disappeared from electrum and the funds became available again in my electrum wallet. I assumed it had dropped out of the network. I entered the transaction again, this time maxing out the fee slider at a 0.000488 BTC fee (again, assuming this would be enough). I sent the transaction. It again showed the low fee warning, but this time the transaction remained pending, and remained so for 3 days. It remained pending in both electrum and coinbase. You can see the transaction here. It is reported here as a double-spend (presumably because of the first, lower-fee attempt. all incoming transactions to my electrum wallet had been confirmed before I sent this one). I've spent the last three days dunking myself into BTC stuck transaction articles and forums. I've learned a shit ton, but haven't found a solution. I've tried ViaBTC's accelerator, but it won't accept my TX ("transaction does not exist error" I think because it is a double spend). Because the transaction is to Coinbase (which withholds private keys) and because it returned no change to electrum, I'm not able to use CPFP to push the TX through. Replace-by-fee confuses me, but as far as I can tell, I would've had to opt-in the transaction in order to use this method, which I did not do. I had almost given up when there was a final twist. I updated electrum to the newest version. When I opened it after the update, it no longer showed the stuck TX in the history, and the BTC were available to be sent. However, Coinbase still lists the TX as pending and it is still visible on blockcypher, blockchain.info, etc. I've read that stuck transactions will eventually be confirmed, I've read that they'll eventually drop out of the network, and I've read that they sometimes remained stuck forever. This leaves me quite confused and unsure how to proceed. Should I send the TX again with a properly calculated fee, now that electrum will allow it? Should I wait longer to see if it will be confirmed or dropped? Any advice on how to proceed would be very much appreciated.
Tom Harding on Jul 15 2015: Spammers out there are being very disrepectful of my fullnode resources these days! I'm making some changes. In case others are interested, here's a description: There is now a maximum size for the memory pool. Space is allocated with a pretty simple rule. For each tx, I calculate MY COST of continuing to hold it in the mempool. I measure the cost to me by "expected byte stay": expectedByteStay = sizeBytes * expectedBlocksToConfirm(feeRate) Rule 1: When there's not enough space for a new tx, I try to make space by evicting txes with expectedByteStay higher than tx. I'm NOT worrying about
Fees EXCEPT via their effect on confirmation time
Coin age You already made money on your old coins. Pay up.
CPFP Child's expectedBlocksToConfirm is max'ed with its parent, then parent expectedByteStay is ADDED to child's
Replacement You'll get another chance in 2 hours (see below).
Rule 2: A transaction and its dependents are evicted on its 2-hour anniversary, whether space is required or not The latest expectedBlocksToConfirm(feeRate) table is applied to the entire mempool periodically. What do you think? I'll let you know how it works out. I'm putting a lot of faith in the new fee estimation (particularly its size independence). Another possibility is clog-ups by transactions that look like they'll confirm next block, but don't because of factors other than fees (other people's blacklists?) original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009419.html
Hey everyone, So, in advance I want to apologize for my stupidity and hope that you won't facepalm too much reading this, but I really need some advice. To be fair, I did quite some transactions in the past and they never were a problem for me. I basically made a transaction via Electrum last Friday, and I still got no confirmation. This is because I sent the tx without any fee (Or without any additional to the standard 0.00003 BTC that Electrum always sets). In the past this always worked, even when I sent larger amounts of bitcoins. But it seems that since the last time, fees became a bigger thing and are now crucial. I tried CPFP, but after calculating it seems that the fee still was around 30% of what it should be. By the time sending, replaceable fee was not activated, so I can not change it. I found https://pushtx.btc.com and wanted to know if that may be an option? I honestly believe that after such a long time, my transaction will take absolutely forever, if it is not stuck already. Im really grateful for any suggestions. Thank you very much.
Future Of Bitcoin-Cores Wallet | Jonas Schnelli | Aug 11 2015
Jonas Schnelli on Aug 11 2015: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi (excuse my english; it’s not my native language) As you might noticed, bitcoin-cores wallet didn’t got that much focus during the last month (even years?). Wallet development has mostly moved towards SPV (bitcoinj), thin clients (Electrum), centralized web middleware (Copay, Greenaddress, etc.). Obviously this direction was highly appreciated by users who now can now run a bitcoin-client (SPV / thin client) on a smartphone or on a computer with tiny available resources. Full validation slowly gets a privilege of people who can manage to run bitcoin-core on a VPS or different server like system. Thought, i think, running a full node wallet could be end user friendly with some changes in the current concept. Today a standard user can download a 1080p 10GB movie over iTunes (in background) and simultaneous play a CPU/GPU extensive 3D game on a standard computer. Why do people think (and it might is) running a full node is so painful? Mainly it could be because bitcoin-core has been focused on doing validation as quick as possible (okay for a server, not desirable for a wallet background service). I could see the following strategy:
- end user focused full node wallet would have enabled pruning by
default (~2GB disk usage).
- throttled validation (flexible CPU usage, user selectable, maybe
~20% by default).
throttled block download (bandwidth).
SPV during catch up (initial sync as also when catching up multiple
days because usenode was offline).
- Disable bloom filtering if there is enough bandwith, keep blocks for
- when node is in sync, switch from SPV to full validation (maybe
maintain to lists/dbs of wtx or re-validate after full catchup and display potential conflicts).
- participate in p2p, but with limits/throttling (service limited
amount of blocks, tx [TBD]). Why?
- This could increase the amount of participating full nodes while
giving users more privacy and security.
- Create a counterweight against SPV/thin clients (avoid wallet
development centralization, could be helpful once/if attacks agains SPV/thin clients are becoming real).
- Slowly complete full validation (can take ~1-2 weeks) and thereforce
increase privacy (avoid bloomfilters) and security. What about SPV together with a full node? Sounds good in theory. But who can run a full node (see above)? How is the channel secured (against MITM, privacy) between the SPV client and the trusted full node? How hard is it to setup and maintain a secure tunnel between a smartphone SPV and a full node over the p2p (8333) channel? How about examine the mempool for fee calculations and (maybe) upcoming CPFP like approaches, etc.? How about smartphones? Obviously the above solution won’t probably work on a smartphone (to much bandwidth and CPU usage). But do you carry your whole saving in your physical wallet with you? Maybe a smartphone does hold keys which protects low value / daily spendings like a physical wallet (=SPV okay). My personal long term vision of that use-case is, that groups of people who trust each other (a family, etc.) might run one or multiple full node(s) on a hardened system (something similar to the bitnodes hardware) where the system could serve smartphones over something like a stratum server (electrum) or bitpays wallet-service does (index blockchain, additional wallet services). Every member still holds it’s keys but they trust the connected full node (full nodes does address index, balance calculation, multisig arrangements and maybe even coin selection). Since about one year i slowly work toward this direction. It took me a while to commit myself to a strategy (and i still shake from time to time). At the moment I am working on a wallet focused bitcoin-core fork with the ability to re-merge it to the bitcoin-core branch (keep the fork rebased). Long term goal is, to decouple the both (wallet / core) by using bitcoin-core as a library (static or shared) for the wallet side (which is possible already now) To myself: I work in the bitcoin-space full-time and completely independent (not employed or influenced by a bitcoin related company) with no business interest, though, i think the acquired know-how can be valuable within the next serval years. And i won’t have any regrets if my work turns out to be unless and ends up in trash. I have set up this mail to avoid parallelism on a works stream (if there is any). Of course i would really appreciate if other developers are willing to join the team by reviewing, concept critism or contributing code at https://github.com/jonasschnelli/bitcoin. Any forms of criticism and any ideas are highly appreciated. — /jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVyboPAAoJECnUvLZBb1PsgkkQAKySrksCclbfwIsf1L4Jwaxp nWmUhlXa3lIoxKG3eYZMPVugFX/LFKtmNqypQJ8whUjF2K5ZwIW1Boosl13cBkE9 2EIAMcBrpah0pwzomJ9ViLArl+7t6ksLR5qWJsgJsLnWlaW4c/1KwjGkYTZ6++VC 8O3M3HrdwT3fnrK35XJXTIhpFfRKRFrWcW98vMFt9xw7MUq+enhloGF6Nw4UiQbi nOV85YleBJEBU5cXuIOznG4EwHH77f8336+GY8d6mLCg7rKj7ZZWqqHztqEQf68Q mtwJhag3pxyW2jqb/fCxYD27oPqgMcLT1lyUobpzu7SrlKKmAIikf8uNU1+8rH+W U1C1IsWzvoPK7g7mqlmpk1/6kvlJOWNshTATfQS2A/hMB1Oec3zZTCz+P5S5g+F7 FT4tB2sR2nwGkWNVPNSs92o0f8y55/u+fAFcbmHkkNrfEt4IuMwsqJNW9i7GzU6b uOznq4ZgYw5OxUJh8uXLaA1OFIdPTEcTA4nNRSA7v6cRbfWeaCSGzafOYdGQKV2Y 5R7VCZJZe8ALzSUr03FsZ5bilcjdJ3ZyeQNikqeYnQLP+qoH6oRhDT0B2GI2E4+4 EvfIZCmaDxYG0FClWOQiiO0WeW2kNBWyD3tWCpM63ri//OnoN65NDKsbIpJ+oD8m OwxleWQP0eC/5knZSFwB =7CG9 -----END PGP SIGNATURE----- original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010137.html
Einige Bitcoin-Wallets und -Dienste unterstützen das Senden und/oder Empfangen an bzw. von Bech32-Adressen noch nicht. ... Das bedeutet, dass diese Wallet es ermöglicht, Gebühren mittels RBF oder CPFP nach dem Verschicken von Bitcoins anzupassen. Darüber hinaus schlägt diese Wallet Gebühren basierend auf den gegenwärtigen Netzwerkbedingungen vor, sodass Ihre Transaktionen zeitnah ... Bitcoin bar cpfp bitcoin sending auszahlen. Beste handelszeit für kryptowährung. Arbeiten von zuhause berlin. Forex tester 3 crack herunterladen. Best stock trading system. 12 kommastellen kryptowährung. Wie trade ich bitcoin. Mit dem hochladen von dateien geld verdienen. Beste forex micro Konto Broker. Risikomanagement im Devisenhandel pdf. Online umfragen geld verdienen gute frage ... Bitcoin Fee Calculator & Estimator. tipo di transazione: Confermare entro blocchi ( ~ min) satoshis/ Per una ... ~ USD . Ulteriori informazioni sulle commissioni Bitcoin... I Bitcoin sono costituiti da blocchi. I blocchi sono un insieme di transazioni e attualmente sono limitati a un importo massimo di 1.000.000 di byte e sono progettati in modo tale da poter creare in media solo 1 blocco ogni ... Free Online CFP franc (XPF) and Bitcoin (BTC) Exchange Rate Conversion Calculator. Source: FCR. Home; Personal Converter Widget; iPhone App; Android App; import_contacts Articles; Please enter the amount you want to convert in any field. change CFP franc (XPF) Fr. Try: 200 + 10%. change Bitcoin (BTC) ¤ Or: (10 + 25) * 4 - 5%. Swap. Source: free currency rates (FCR) Updated: October 07, 2020 ... Mining Calculator This website is made possible and remain free by displaying online advertisements to our users. Please consider supporting us by pausing your ad blocker or whitelisting this website.
Must Video for Every CFP Aspirant by Mr. Keyur Shah, India's Best Expert Coach Fast Track CFP - Duration: 58:15. Keyur Shah CBOT DoubleSure Practical CFP 10,257 views Live updating list of new bitcoin transactions which are unconfirmed. Can Banks Ban Bitcoin ? Make Money With Bitcoin Now - https://goo.gl/pK4VTx Buy and Trade Bitcoin and altcoins on Binance - https://goo.gl/NKgfPi Buy a... This video is unavailable. Watch Queue Queue. Watch Queue Queue We’ll stop supporting this browser soon. For the best experience please update your browser.