Cryptocurrency TxID Explained: Find Transaction in Open Ledger

/u/jl_2012 comments on new extension block BIP - "a block reorg will almost guarantee changing txid of the resolution tx, that will permanently invalidate all the child txs based on the resolution tx" /r/Bitcoin

jl_2012 comments on new extension block BIP - submitted by BitcoinAllBot to BitcoinAll [link] [comments]

More fun with OP_HODL (CheckLockTimeVerify)

Last week I wrote a post with a script to create a HODL address. A HODL address is a UTXO that cannot be spent until a certain epoch time or blocktime. It can be used to secure funds in a will or trust that has a designated maturity date. Or you may have some other reason to lock the funds, the point is that the UTXO can be physically verified to be funded, and under an unbreakable timelock.
I've liked the feature but have been frustrated that there is limited HW and SW wallet support for it presently. My previous post walked through how to make a segwit HODL UTXO, this post will detail how to make a BIP16 legacy P2SH HODL UTXO.
Similar to last week, I wrote a bitcoinlib script to do it, but this week I also went through the steps to do it on the CoinBin wallet. CoinBin is a JavaScript wallet that can (and should) be run locally. CoinBin, or raw python (bitcoinlib) are the only ways I currently know of to spend a HODL address.
Here's the basic rundown to create and fund your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect a Bitcoin public and private key.
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Time Locked Address
  4. Enter the public key (from #1) and either a block height or timestamp for your lock
  5. Hit Submit and record the address and redeem script
  6. Ensure you have accurately recorded everything in step #1 and step #5
  7. Send funds to the address recorded in step 5 as you normally would.
Here's the basic rundown on how to spend your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect an address to spend your UTXO to
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Transaction
  4. Enter the Redeem Script you copied in the creation process (step #5), then Load
  5. After a few minutes it should automatically load your UTXO into the form
  6. Enter the address you want to spend your UTXO to and adjust the output amount for fees
  7. Hit the question mark next to Transaction Fee for the calculator
  8. Hit Submit when satisfied and record the unsigned transaction data
  9. Select Sign on the top nav bar to begin the signing operation
  10. Enter your private key from the creation process (step #1) and the unsigned TXN
  11. Select Submit to produce the signed TXN
  12. Broadcast the signed TXN with either Electrum or Bitcoin Core
Note, if you try to broadcast before the UTXO's timelock expires, you will get a terse not final error in either Electrum or Core.
For Extra Credit, CoinBin can also be run against Testnet, but to do so you have to unhide the settings element, manually code the TXN input script and manually code the TXN nLockTime to sync with your HODL address.
Here are a Testnet and Mainnet HODL spend TXN I created in CoinBin * Mainnet: txid ea6a1...79d53 * Testnet: txid a8110...adc93
submitted by brianddk to Bitcoin [link] [comments]

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.

Highlights

Protocol

Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.

GUI

Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.

Blockchain

The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog

Accrual

Changed

Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

The Bitcoin Cash (BCH) Marketing Flipstarter expired without reaching its target

Earlier today the Flipstarter Campaign for Bitcoin Cash (BCH) Marketing expired without reaching its target. It ran for 22 days and at its peak accumulated over 350 BCH from 36 generous contributors. This was over 50% of the funding goal of 650 BCH ($200,000 at time of campaign launch). I would like to thank those who supported the Flipstarter with hopes of it succeeding. It means a lot knowing that I have so much support and appreciation for my work in the Bitcoin Cash community.
I have said that if the Flipstarter failed I would move on and do other things with the time which I allocated toward the Bitcoin Cash (BCH) Marketing campaign. However, numerous contributors of the Flipstarter have contacted me to say they believe I should run it again with a smaller scope and duration for the campaign. I have had some time to consider this and ultimately decided I will satisfy their demands by amending the Flipstarter and attempting it a second time. The new Flipstarter will request 360 BCH ($100,000 at time of writing) to conduct Bitcoin Cash (BCH) Marketing in the form of high quality videos, over the course of 12 months. This target should be met given that the amount was already raised on the first attempt. I have set the campaign expiry for 8/9/2020 but should it fail again I will move forward with my original intentions.
If you contributed to the original Flipstarter campaign, please go into Electron Cash and cancel your pledge. That will enable you to contribute those funds again to the new campaign. Alternatively, you can contribute directly to this address (bitcoincash:qpu9yl4eh9rtt4z8d92qcmqrsxcfs783zuk5hx07jh) and I will contribute it on your behalf. Leave a comment below with your TXID so I know which name to attribute to the contribution.
If you do not know how to contribute, please watch this video guide: https://youtu.be/g7tcZu3t4hc
Thank you all for your support! You can contribute to the new campaign here: https://flipstarter.bitcoinbch.com
submitted by CryptoStrategies to btc [link] [comments]

Dust attack?

Recently i updat my Trezor T to the newest version and I notice that someone send me a very small amount of Bitcoin. I follow the sending address and fund out that it was a couple of thousand of people that received same amount of Bitcoin. I did some reading about it and i find out that i could be dust attack and someone could trace my wallet if spend it and try to find out my real identity. i heard that Samuraj wallet have a option that you could marke TXid as "do not spend" , i tray to find out if Trezor have something thing like that in the options and i couldn't find it. So my question is how i can go about it. How can I mark that TXid to not spend it. My plan is to transfer all to new seed wallet but I don't want to include that dust in my transaction.
submitted by EmotionalUnstable to TREZOR [link] [comments]

Electrum unable to sign transaction properly

I'm new to using bitcoin and I'm trying to figure out a problem I've been having trying to broadcast a transaction with Electrum. Initially I was trying to send bitcoin using Electrum's built in "send" function, but kept receiving the error "scriptpubkey." After browsing other forums and seeing issues similar to what I was having, it seemed like people were saying that it was an issue with the server I was connected to. In some cases, people had to try 15-20 different servers before finally being able to send the transaction through.
I thought this was the probable cause of my situation as well so tried about 20 different servers but to no avail. Then I read about "pushing the raw hex transaction" (not sure if I am using the right lingo here) and decided to try that. I was able to make an offline transaction with Electrum and signed it, then obtained the hex code from the .txn file that was created.
I then tried to broadcast the hex code on blockchain.com/btc/pushtx, but I am still receiving the error " Code: -26, Error: scriptpubkey."
So after doing some more research it seems that my problem now is not that there was an issue with servers in Eluctrum, but rather my transactions are not being properly signed. So now I have a signed offline transaction that seems to be improperly signed by Electrum, and I am clueless as to how to correct this.
Is there a way to "unsign" the transaction and sign it again properly? How would I even go about doing that? I fear that I now have money locked up in this faulty transaction that I may not be able to recover. I have all my passwords and everything so I am confused why Electrum would not have signed it properly. I am very new to all this so I'm sure I could be missing something essential. Any advice on how to broadcast and complete my transaction would be much appreciated.
I am running the latest version of Electrum on a Windows 10 computer.

Thanks!
Edit: Latest version of Electrum being 4.0.2
Also, I suppose it is probably helpful to see the decoded transaction here:
{ "version": 2, "locktime": 644562, "ins": [ { "n": 50, "script": { "asm": "", "hex": "" }, "sequence": 4294967293, "txid": "9bc2e9464a58f7d8017fc332f064eb4faf2773daa3251d5194bb851f07afe8c5", "witness": [ "3044022066e5aa2f97647eb34377a1937dc6b7dcad81c652a23c2a5be20e07e2b1af39cf02207bc07ac253b4480c07c4b2d8494d6b18d98a4b17c4bf057468b81d95655f4aa101", "0319a1a5408ccbf7cba4d569bd14b779ded4bbedec040ab84fd9c88d79ab7410fe" ] }, { "n": 8, "script": { "asm": "", "hex": "" }, "sequence": 4294967293, "txid": "dc4e13e07f74b51e623669e2b6f05f7e6e7fa173c07ffcea73b9e84462e6e3c6", "witness": [ "3044022027822d6a6531fa3a4c2b3edfc189afdfad985ade643ebb208eb15174779400b102201db77e06d6158639ae320be5123a3effc00dff48eddf17c03c699334ea58d25a01", "031399274350b7f4888cc34ca1fa1fd915d8e90222026fc89c2d5d42574e0cf7eb" ] } ], "outs": [ { "script": { "addresses": [], "asm": "039135a7d4a9df8a21977f0765ea5667e931be9d1e1f7666d1e264ef539c2c2157", "hex": "21039135a7d4a9df8a21977f0765ea5667e931be9d1e1f7666d1e264ef539c2c2157" }, "value": 1208329 } ], "hash": "b2b8209b1c0e46cddb6ded0758fc8287a97e6b2bd1f88290c1d374b0bab4a6c8", "txid": "b2b8209b1c0e46cddb6ded0758fc8287a97e6b2bd1f88290c1d374b0bab4a6c8" } 

submitted by Arug_1 to Electrum [link] [comments]

Mining pool's mining detail

Since the Bitcoin core does not support mining from version 0.13.0,I think there are some mining strategy but I can not obtain them from Bitcoin Core's source code.
I want to ask some details about mining:
  1. When packaging a new block, generally speaking, the number of transactions in the transaction pool is about 10,000 to 20,000, far exceeding the transactions that can be accommodated in a block (up to 3000), How does the mining pool selects the transaction from the transaction pool? Is it knapsack algorithm or a greedy algorithm? Or some other more complicated algorithm?
  2. After the transactions are choosed, will the transactions be sorted by some rules(may be by txid)?
  3. If all the nonces, timestamp and coinbase in the current block have been tried and still cannot mine a new block, what does the mining pool do? will the mining pool adjust the order between transactions? If it is to adjust the order between transactions, are there any adjustment rules?
It would be great if there were relevant technical experts who could introduce it. Thanks again!
submitted by HumbleMine1395 to Bitcoin [link] [comments]

How Do Bitcoin Transactions Work?

Now that you’ve set up your bitcoin wallet and are ready to make your first transaction, let’s take a look at how bitcoin transactions actually work.
There are three key variables in any bitcoin transaction: an amount, an input and an output. An input is the address from which the money is sent, and an output is the address that receives the funds. Since a wallet can contain several input addresses, you can send money from one or more inputs to one or more outputs. There is also a data storage portion on each transaction, a sort of note, that allows you to record data to the blockchain immutably.
But the unique thing about bitcoin transactions is that, if you initiate a transaction that’s worth less than the total amount in your input, you get your change back not to your original output, but through a new third address in your control. This means your wallet typically ends up containing multiple addresses, and you can pull funds from these addresses to make future transactions.
You’ve learned how to buy and store your bitcoins, so you already know what public and private keys are for, and you’ll need these to issue a transaction. To do that, you put your private key, the amount of bitcoins you want to send and the output address into the bitcoin software on your computer or smartphone.
Then the program generates a signature made from your private key to announce this transaction to the network for validation. The network needs to confirm that you own the bitcoin being transferred and that you haven’t spent it by checking all previous transactions which are public on the ledger. Once the bitcoin program verifies that indeed your private key corresponds to the provided public key (without knowing what your private key is), your transaction is confirmed.
This transaction is now included in a “block” which gets attached to the previous block to be added to the blockchain. Every transaction in the blockchain is tied to a unique identifier called a transaction hash (txid), which looks like a 64-character string of random letters and numbers. You can track a particular transaction by typing this txid in the search bar on the blockchain explorer.
Transactions can’t be undone or tampered with, because it would mean re-doing all the blocks that came after. This process is not instantaneous. Because the bitcoin blockchain is fairly large, it takes a lot of time to process a single transaction among the many on the blockchain.
The amount of time it takes to confirm a transaction varies, ranging anywhere from a few minutes to a couple days, based on traffic on the blockchain and the size of your transaction. Larger transactions with higher fees tend to get validated by miners quicker than smaller ones. That said, once it is confirmed, it is immutably recorded forever.
If you want to indulge in some mindless fascination, you can sit at your desk and watch bitcoin transactions float by. Blockchain.info is good for this, but try BitBonkers if you want a hypnotically fun version.
submitted by hackatoshi to u/hackatoshi [link] [comments]

Technical: A Brief History of Payment Channels: from Satoshi to Lightning Network

Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value?
So let's have a short history of various payment channel techs!

Generation 0: Satoshi's Broken nSequence Channels

Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product.
Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger.
Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore.
In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction.
So what you'd do would be something like this:
  1. You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
  2. For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
  3. For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
  4. Eventually you have to stop drinking. It comes down to one of two possibilities:
    • You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
    • You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time.
Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
  1. Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
  2. Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
  3. When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
  4. Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
  5. The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
  6. Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
  7. The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
  8. Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
  9. I think I got sidetracked here.
Lessons learned?

Spilman Channels

Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is).
Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender.
Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender.
First, you and the bartender perform this ritual:
  1. You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
  2. You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
  3. The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
  4. Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds.
So now you start ordering in this way:
  1. For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
  2. You sign the transaction and pass it to the bartender, who serves your first drink.
  3. For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
  4. At the end:
    • If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
    • If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
    • If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen.
So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx...
Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly.
"I'm refusing service to you," the bartender says.
"Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!"
"Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed."
"What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer.
What you see shocks you.
"What the --- the txid is different! You--- you changed my signature?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!"
"Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by separating the signatures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW."
Lesson learned?

CLTV-protected Spilman Channels

Using CLTV for the backoff branch.
This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015.
Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed.
This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction.
With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to.
Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time".
With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.

Todd Micropayment Networks

The old hub-spoke model (that isn't how LN today actually works).
One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel.
Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable.
So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user).
In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today.
Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy.
Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.

Poon-Dryja Lightning Network

Bidirectional two-participant channels.
The Poon-Dryja channel mechanism has two important properties:
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel.
The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online.
Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want.
Both properties, together, form a very powerful scaling property that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening.
With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow.
I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere.
There is a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit):
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network.
Lessons learned?

Future

After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time.
The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory).
Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough.
Lessons learned?
submitted by almkglor to Bitcoin [link] [comments]

Megacoin MΣC 1.9.9.x - Release Notes - Short Overview

Megacoin MΣC 1.9.9.x - Release Notes - Short Overview

https://preview.redd.it/3ex64pfi6k251.jpg?width=1452&format=pjpg&auto=webp&s=c029b11966e1215b4bb95be70756923830c150a6

Masternodes
Megacoin MΣC 1.9.9.x brings along a masternode system for Bitcore. The collateral for one masternode is 4,200 MΣC . This allows up to 10,000 masternodes to support the network. The masternodes receive half of all generated bitcores. It is possible to setup a masternode with the minimum version 1.9.9.x or higher. A government system is included in the new core
Datacarriersize

https://preview.redd.it/jyf7ka176k251.jpg?width=1288&format=pjpg&auto=webp&s=cd6f881532ffb0b26f02bc19ca73ecb52882748a
Megacoin MΣC 1.9.9.x increase the default datacarriersize up to 220 bytes. More infos con you find here | here no 2. | here no 3.
Command fork system
Different forks can be activated remotely in the future. This way we can ensure that all critical updates are only activated once all important network participants are ready.
Wallet changes
Megacoin MΣC 1.9.9.x introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.
A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate.
A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions.
All segwit addresses created through `getnewaddress` or `*multisig` RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date.
All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software.
All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work
Note that some RPCs do not yet support segwit addresses. Notably, `signmessage`/`verifymessage` doesn't support segwit addresses, nor does `importmulti` at this time. Support for segwit in those RPCs will continue to be added in future versions.
P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case.
BIP173 (Bech32) Address support ("mec.." addresses)

https://preview.redd.it/kzg55cg36k251.jpg?width=1288&format=pjpg&auto=webp&s=288ac36af63f4f5040ca2d20c9d8f07b78d99a5a

Full support for native segwit addresses (BIP173 / Bech32) has now been added.
This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these addresses (including as default new addresses, see above).
A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled.
HD-wallets by default
Due to a backward-incompatible change in the wallet database, wallets created with version 0.15.2 will be rejected by previous versions. Also, version 0.15.2 will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD.
Replace-By-Fee by default in GUI
The send screen now uses BIP125 RBF by default, regardless of `-walletrbf`.There is a checkbox to mark the transaction as final.
The RPC default remains unchanged: to use RBF, launch with `-walletrbf=1` oruse the `replaceable` argument for individual transactions.
Wallets directory configuration (`-walletdir`)
Megacoin MΣC 1.9.9.x now has more flexibility in where the wallets directory can belocated. Previously wallet database files were stored at the top level of thebitcoin data directory. The behavior is now:
For new installations (where the data directory doesn't already exist), wallets will now be stored in a new `wallets/` subdirectory inside the data directory by default.
For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a `wallets/` subdirectory already exists in the data directory root, then wallets will be stored in the `wallets/` subdirectory by default.- The location of the wallets directory can be overridden by specifying a
`-walletdir=` option where `` can be an absolute path to a directory or directory symlink.
Care should be taken when choosing the wallets directory location, as if itbecomes unavailable during operation, funds may be lost.
Support for signalling pruned nodes (BIP159)


Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation forfull BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.
GUI changes
We have added a new Walletdesign. The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone.- Support for searching by TXID has been added, rather than just address and label.- A "Use available balance" option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output.- A toggle for unblinding the password fields on the password dialog has been added
Security
We change the coinbase maturity via command fork from 100 to 576 blocks. Also we have pumb the default the protoversion to 70006. It is possible later to disconnect the old version via command fork.
Hashalgorythm
Megacoin MΣC 1.9.9.x supports a completely new hashalgo "Mega_MEC".
Sources
Bitcoin Core, Dash Core, FXTC Core, LTC Core, PIVX Core, Bitcoin Cash Core, Bitcore BTX Odarhom
submitted by limxdev to megacoinmec [link] [comments]

Odarhom - Release Notes - Short Overview - First Draft

Odarhom - Release Notes - Short Overview - First Draft

Odarhom
Masternodes
Odarhom brings along a masternode system for Bitcore. The collateral for one masternode is 2,100 BTX. This allows up to 10,000 masternodes to support the network. The masternodes receive half of all generated bitcores. It is possible to setup a masternode with the minimum version 0.90.8.x or higher. A government system is included in the new core and can be activated later, if necessary.
Datacarriersize

https://preview.redd.it/csrmknzl58q41.jpg?width=1267&format=pjpg&auto=webp&s=85c59b3e5753009f397505c3000e6d70892188b7
Odarhom increase the default datacarriersize up to 220 bytes. More infos con you find here | here no 2. | here no 3.
Command fork system
Different forks can be activated remotely in the future. This way we can ensure that all critical updates are only activated once all important network participants are ready.
Wallet changes
Odarhom introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used.
A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate.
A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions.
All segwit addresses created through `getnewaddress` or `*multisig` RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date.
All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software.
All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work
Note that some RPCs do not yet support segwit addresses. Notably, `signmessage`/`verifymessage` doesn't support segwit addresses, nor does `importmulti` at this time. Support for segwit in those RPCs will continue to be added in future versions.
P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case.
BIP173 (Bech32) Address support ("btx..." addresses)

https://preview.redd.it/q0c26p3fx7q41.jpg?width=1278&format=pjpg&auto=webp&s=bd2b8c5d583dca703caae940aa44e01a365f080c
Full support for native segwit addresses (BIP173 / Bech32) has now been added.
This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these addresses (including as default new addresses, see above).
A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled.
HD-wallets by default
Due to a backward-incompatible change in the wallet database, wallets created with version 0.15.2 will be rejected by previous versions. Also, version 0.15.2 will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD.
Replace-By-Fee by default in GUI
The send screen now uses BIP125 RBF by default, regardless of `-walletrbf`.There is a checkbox to mark the transaction as final.
The RPC default remains unchanged: to use RBF, launch with `-walletrbf=1` oruse the `replaceable` argument for individual transactions.
Wallets directory configuration (`-walletdir`)
Odarhom now has more flexibility in where the wallets directory can belocated. Previously wallet database files were stored at the top level of thebitcoin data directory. The behavior is now:
For new installations (where the data directory doesn't already exist), wallets will now be stored in a new `wallets/` subdirectory inside the data directory by default.
For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a `wallets/` subdirectory already exists in the data directory root, then wallets will be stored in the `wallets/` subdirectory by default.- The location of the wallets directory can be overridden by specifying a
`-walletdir=` option where `` can be an absolute path to a directory or directory symlink.
Care should be taken when choosing the wallets directory location, as if itbecomes unavailable during operation, funds may be lost.
Support for signalling pruned nodes (BIP159)

https://preview.redd.it/fctdedmwx7q41.jpg?width=1283&format=pjpg&auto=webp&s=20dafb6385f46a072f68d49fd0e9a294341be684
Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation forfull BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers.
GUI changes
We have added a new Walletdesign. The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone.- Support for searching by TXID has been added, rather than just address and label.- A "Use available balance" option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output.- A toggle for unblinding the password fields on the password dialog has been added
Security
We change the coinbase maturity via command fork from 100 to 576 blocks. Also we have pumb the default the protoversion to 80004. It is possible later to disconnect the old version via command fork.
Hashalgorythm
Odarhom supports already lots of Hashalgorythms so can we later with an update new Hashalgorythms for mining. A final decision will be agreed with the community. Odarhom can work with timetravel10, scrypt, nist5, lyra2z, x11, x16r.
Sources
Bitcoin Core, Dash Core, FXTC Core, LTC Core, PIVX Core, Bitcoin Cash Core
submitted by limxdev to bitcore_btx [link] [comments]

[How-To] Crafting an offline TXN with the trezorlib python API

With the rollout of the new 0.12.0 Trezor API, I thought it might be time to update some of my old offline_txn scripts. The following is about 80 lines of python that will craft and sign a VERY simple transaction on Testnet.
The new rollout also comes with some new tools. The build_tx.py that is useful in conjunction with the trezorctl sign_tx command.
Both of the methods below will produce a signed TXN that can then be imported into Electrum using the "Tools -> Load transaction -> From text" command.
Note: u/Crypto-Guide has a good walkthrough for installing trezorlib in Windows if you haven't already done that.

Example of using trezorctl btc sign-tx

This example uses the build_tx.py script to build JSON to feed to the sign-tx command. You will need to download the build_tx.py file from github. It is not automatically installed with the trezor package.
```

python build_tx.py | trezorctl btc sign-tx -

Coin name [Bitcoin]: Testnet Blockbook server [btc1.trezor.io]: tbtc1.trezor.io
Previous output to spend (txid:vout) []: e294c4c172c3d87991...060fad1ed31d12ff00:0 BIP-32 path to derive the key: m/84'/1'/0'/0/0 Input amount: 129999866 Sequence Number to use (RBF opt-in enabled by default) [4294967293]: Input type (address, segwit, p2shsegwit) [segwit]:
Previous output to spend (txid:vout) []:
Output address (for non-change output) []: 2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3 Amount to spend (satoshis): 129999706
Output address (for non-change output) []: BIP-32 path (for change output) []: Transaction version [2]: Transaction locktime [0]: Please confirm action on your Trezor device.
Signed Transaction: 0200000000010100ff121dd31ead0f06...f279b642d85c48798685f86200000000 ```

Example of using crafting a TXN using trezorlib directly

If your good with python, or want to see how everything works under the hood, here's 80 lines of python to generate a similar signed transaction.
```python

!/usbin/env python3

[repo] https://github.com/brianddk/reddit ... python/offline_txn.py

[req] pip3 install trezor

from trezorlib import btc, messages as proto, tools, ui from trezorlib import MINIMUM_FIRMWARE_VERSION as min_version from trezorlib.client import TrezorClient from trezorlib.transport import get_transport from trezorlib.btc import from_json from json import loads from decimal import Decimal from sys import exit

Tested with SLIP-0014 allallall seed (slip-0014.md)

User Provided Fields; These are pulled from test scripts

CHANGE THESE!!!

coin = "Testnet"

Get legacy UTXO prev_txn hex from blockbook server. For example:

https://tbtc1.trezor.io/api/tx-specific/ \

e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00

in1_prev_txn_s = '{"txid":' \ '"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00"}'
in1_prev_index = 0 in1_addr_path = "m/84'/1'/0'/0/0" # allallall seed in1_amount = 129999867 out1_address = "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" out1_amount = in1_amount - 192

Defaults

tx_version = 2 tx_locktime = 0 sequence = 4294967293

Code

in1_prev_txn_j = loads(in1_prev_txn_s, parse_float=Decimal) in1_prev_hash = in1_prev_txn_j['txid'] in1_prev_hash_b = bytes.fromhex(in1_prev_hash) device = get_transport() client = TrezorClient(transport=device, ui=ui.ClickUI())
fw_version = (client.features.major_version, client.features.minor_version, client.features.patch_version) if fw_version < min_version[client.features.model]: print("Please flash to the latest FW") exit(1)
signtx = proto.SignTx( version = tx_version, lock_time = tx_locktime )
ins = [proto.TxInputType( address_n=tools.parse_path(in1_addr_path), prev_hash=in1_prev_hash_b, prev_index=in1_prev_index, amount=in1_amount, script_type=proto.InputScriptType.SPENDWITNESS, sequence=sequence )] outs = [proto.TxOutputType( address=out1_address, amount=out1_amount, script_type=proto.OutputScriptType.PAYTOADDRESS )]
txes = None for i in ins: if i.script_type == proto.InputScriptType.SPENDADDRESS: tx = from_json(in1_prev_txn_j) txes = {in1_prev_hash_b: tx} break
_, serialized_tx = btc.sign_tx(client, coin, ins, outs, details=signtx, prev_txes=txes) client.close() print(f'{{"hex": "{serialized_tx.hex()}"}}') ```
From here, you simple take the resultant TXN hex and import it into Electrum using the "Tools -> Load transaction -> From text" clickpath
submitted by brianddk to Bitcoin [link] [comments]

By the power of CTOR! Xthinner is now working with BCH mainnet blocks

A few hours ago, I fixed the last showstopping bug in my Xthinner code and got it running between two of my ABC full nodes on mainnet. One node serves as a bridge to the rest of the world, receiving Compact Blocks and transmitting Xthinner. The other is connected to no other nodes except this bridge.
The first block transmitted by Xthinner was #577,310. My nodes had just started when that block was published, so it was transmitted with only 24 transactions in mempool out of 2865 total in the block. It worked nonetheless. Xthinner has worked on every block since then, with no failures, and with no block taking more than 1.5 networking round trips. Most non-tiny blocks have gotten about 99.0% compression after fetching missing transactions, or about 99.3% before fetching. In comparison, Compact Blocks usually gets about 96-97% edit: 98.5% compression. Eight blocks have been complete on arrival without any missing transaction fetching (0.5 round trips), and 24 blocks have required a round trip to fetch missing transactions. Edit: This missing transaction rate is quite high, and probably the result of the chained-nodes test setup. Each hop in a node chain adds up to 5 seconds of delay in transaction propagation, and this setup has 2 chain hops. I expect performance to improve in more normal configurations.
I will probably make an alpha code release soon so that people can play around with it. The code still has some known bugs and vulnerabilities, though, so don't run it on anything you want to stay running. There's still a lot of work to be done before the code is of high enough quality to be merged into Bitcoin ABC, so don't get too excited.
Here's the best-performing block so far:
2019-04-08 09:27:53.076818 received: xtrblk (1660 bytes) peer=0 2019-04-08 09:27:53.077210 Filling xtrblk with mempool size 841 2019-04-08 09:27:53.077644 xtrblk: 841 tx, 1 prefilled 2019-04-08 09:27:53.077707 Received complete xthinner block: 000000000000000002f914b0c6afb568bec86b9a5166a5023f466c5ee7100e90. 2019-04-08 09:27:53.136257 UpdateTip: new best=000000000000000002f914b0c6afb568bec86b9a5166a5023f466c5ee7100e90 height=577332 version=0x20800000 log2_work=87.837579 tx=269896356 date='2019-04-08 09:27:30' progress=1.000000 cache=10.6MiB(79763txo) warning='40 of last 100 blocks have unexpected version' 
This was a 841 tx, 363 kB block transmitted in 1660 bytes. That's 99.54% compression or 15.79 bits/tx. Uncoincidentally, this was also one of the largest blocks so far, with 23 minutes elapsed since the prior block.
Bigger blocks get better compression because the header, coinbase, and checksum specification overhead is a smaller proportion of the whole, and sometimes also because the Xthinner algorithm can more consistently omit the initial bytes of the TXID.
Sizes of the xtrblk messages:
2019-04-08 06:17:48.394401 received: xtrblk (4511 bytes) peer=0 2019-04-08 06:34:40.219904 received: xtrblk (1249 bytes) peer=0 2019-04-08 06:50:25.290082 received: xtrblk (1209 bytes) peer=0 2019-04-08 06:51:49.082137 received: xtrblk (282 bytes) peer=0 2019-04-08 07:04:02.028427 received: xtrblk (416 bytes) peer=0 2019-04-08 07:09:44.603728 received: xtrblk (1235 bytes) peer=0 2019-04-08 07:15:32.338061 received: xtrblk (351 bytes) peer=0 2019-04-08 07:17:25.983502 received: xtrblk (839 bytes) peer=0 2019-04-08 07:19:38.947229 received: xtrblk (498 bytes) peer=0 2019-04-08 07:21:22.099113 received: xtrblk (404 bytes) peer=0 2019-04-08 07:37:20.573195 received: xtrblk (569 bytes) peer=0 2019-04-08 07:38:41.106193 received: xtrblk (1259 bytes) peer=0 2019-04-08 07:46:40.656947 received: xtrblk (764 bytes) peer=0 2019-04-08 07:52:40.203599 received: xtrblk (591 bytes) peer=0 2019-04-08 08:01:30.239679 received: xtrblk (776 bytes) peer=0 2019-04-08 08:26:06.212842 received: xtrblk (287 bytes) peer=0 2019-04-08 08:37:10.882075 received: xtrblk (2177 bytes) peer=0 2019-04-08 08:39:05.003971 received: xtrblk (392 bytes) peer=0 2019-04-08 08:40:27.191932 received: xtrblk (274 bytes) peer=0 2019-04-08 08:53:57.338920 received: xtrblk (1294 bytes) peer=0 2019-04-08 08:54:44.033299 received: xtrblk (344 bytes) peer=0 2019-04-08 09:04:55.541082 received: xtrblk (947 bytes) peer=0 2019-04-08 09:27:53.076818 received: xtrblk (1660 bytes) peer=0 2019-04-08 09:39:21.527632 received: xtrblk (878 bytes) peer=0 2019-04-08 09:48:57.831915 received: xtrblk (836 bytes) peer=0 2019-04-08 09:49:18.074036 received: xtrblk (243 bytes) peer=0 2019-04-08 09:52:09.949254 received: xtrblk (474 bytes) peer=0 2019-04-08 10:05:35.192227 received: xtrblk (451 bytes) peer=0 2019-04-08 10:12:37.671585 received: xtrblk (1317 bytes) peer=0 2019-04-08 10:12:40.761272 received: xtrblk (294 bytes) peer=0 2019-04-08 10:13:10.548404 received: xtrblk (278 bytes) peer=0 2019-04-08 10:17:06.108110 received: xtrblk (512 bytes) peer=0 
Sizes of the fetched missing transactions:
2019-04-08 06:17:48.410703 received: xtrtxn (842930 bytes) peer=0 2019-04-08 06:34:40.221133 received: xtrtxn (5691 bytes) peer=0 2019-04-08 06:50:25.291309 received: xtrtxn (517 bytes) peer=0 2019-04-08 07:04:02.029652 received: xtrtxn (3461 bytes) peer=0 2019-04-08 07:09:44.604922 received: xtrtxn (744 bytes) peer=0 2019-04-08 07:15:32.339450 received: xtrtxn (1155 bytes) peer=0 2019-04-08 07:17:25.984684 received: xtrtxn (3337 bytes) peer=0 2019-04-08 07:19:38.948412 received: xtrtxn (654 bytes) peer=0 2019-04-08 07:21:22.100418 received: xtrtxn (3510 bytes) peer=0 2019-04-08 07:37:20.574477 received: xtrtxn (3990 bytes) peer=0 2019-04-08 07:38:41.107558 received: xtrtxn (519 bytes) peer=0 2019-04-08 07:52:40.204659 received: xtrtxn (2364 bytes) peer=0 2019-04-08 08:01:30.240842 received: xtrtxn (275 bytes) peer=0 2019-04-08 08:26:06.214200 received: xtrtxn (274 bytes) peer=0 2019-04-08 08:39:05.005097 received: xtrtxn (273 bytes) peer=0 2019-04-08 08:53:57.340233 received: xtrtxn (514 bytes) peer=0 2019-04-08 08:54:44.034397 received: xtrtxn (1243 bytes) peer=0 2019-04-08 09:04:55.542438 received: xtrtxn (420 bytes) peer=0 2019-04-08 09:39:21.528842 received: xtrtxn (811 bytes) peer=0 2019-04-08 09:49:18.075155 received: xtrtxn (274 bytes) peer=0 2019-04-08 09:52:09.950762 received: xtrtxn (10478 bytes) peer=0 2019-04-08 10:05:35.193791 received: xtrtxn (8248 bytes) peer=0 2019-04-08 10:12:40.762645 received: xtrtxn (1741 bytes) peer=0 
As a reminder: Xthinner does not affect storage, RAM, or CPU requirements for full nodes in any way, and has very little effect on total network traffic, which is dominated by tx announcements and historical block uploads. Xthinner's compression only affects block propagation speed. Block propagation is the code path that is most sensitive to performance and latency for keeping Bitcoin decentralized while scaling, and has long been a sore point, so this optimization is worthwhile. But its effects are limited to that code path.
Edit 4/18/2019: I tracked down the cause of the high missing/colliding transaction rate and associated extra round trips to an off-by-one bug in my encoder. The code was checking how many bytes were needed to disambiguate from the 2nd-closest mempool match instead of the closest mempool match. Since fixing this bug a few hours ago, only 1 out of 27 block transmission attempts have required an extra round trip for tx fetching.
submitted by jtoomim to btc [link] [comments]

Monero PHP help

I had 2 quick ques. I'm trying to use the monero PHP library to decrypt a transaction pulled from a block explorer so that I can avoid sending my private view key to 3rd parties.
use MoneroIntegrations\MoneroPhp\Cryptonote;
use MoneroIntegrations\MoneroPhp\ed25519;
require_once('Cryptonote.php');
require_once('ed25519.php');
require_once('SHA3.php');
require_once('base58.php');
require_once('Varint.php');

$cn = new Cryptonote();
$tx = json_decode(file_get_contents('https://moneroblocks.info/api/get_transaction_data/insert txid here'), true);
$extra = implode(array_map(function($x){ return str_pad(dechex($x), 2, '0', STR_PAD_LEFT); }, $tx['transaction_data']['extra']));

$derived = $cn->gen_key_derivation($cn->txpub_from_extra($extra), 'insert private view key here');

if( $cn->derive_public_key($derived, 'transaction ioutput index', 'insert public spend key here') == $tx['transaction_data']['vout'][0]['target']['key']){
`$sec1 = $cn->derivation_to_scalar($derived, 'transaction ioutput index');` `$sec2 = $cn->hash_to_scalar($sec1);` `$ec = new ed25519();` `echo bcsub($ec->decodeint(hex2bin($tx['transaction_data']['rct_signatures']['ecdhInfo'][0]['mask'])), $ec->decodeint(hex2bin($sec1)));` `echo bcsub($ec->decodeint(hex2bin($tx['transaction_data']['rct_signatures']['ecdhInfo'][0]['amount'])), $ec->decodeint(hex2bin($sec2)));` 
}

1- How are subaddresses handled? From this code so far my best guess is just looping through the public spend keys of all subaddresses but I assume that isn't correct.
2- How do I decode amounts? It seems like there's a few variations of it, I'd want to support both the 64 character long mask/amount as well as the 16 character long amount; most examples I've seen seem to be incomplete or missing portions of the code.
3- Is there a good way to sanity check the received transactions? (so we limit the 3rd party API to only possibly omitting transactions, but make sure they aren't able to send fake transactions). I'm assuming trying to validate the signatures will be impractical without just using the official client, but not sure if something simpler like Bitcoin's merkle hash validation exists.
Thanks
submitted by EnvironmentalSpeech3 to Monero [link] [comments]

[How-To] Crafting an offline TXN with the trezorlib python API

With the rollout of the new 0.12.0 API, I thought it might be time to update some of my old offline_txn scripts. The following is about 80 lines of python that will craft and sign a VERY simple transaction on Testnet.
The new rollout also comes with some new tools. The build_tx.py that is useful in conjunction with the trezorctl sign_tx command.
Both of the methods below will produce a signed TXN that can then be imported into Electrum using the "Tools -> Load transaction -> From text" command.
Note: u/Crypto-Guide has a good walkthrough for installing trezorlib in Windows if you haven't already done that.

Example of using trezorctl btc sign-tx

This example uses the build_tx.py script to build JSON to feed to the sign-tx command. You will need to download the build_tx.py file from github. It is not automatically installed with the trezor package.
```

python build_tx.py | trezorctl btc sign-tx -

Coin name [Bitcoin]: Testnet Blockbook server [btc1.trezor.io]: tbtc1.trezor.io
Previous output to spend (txid:vout) []: e294c4c172c3d87991...060fad1ed31d12ff00:0 BIP-32 path to derive the key: m/84'/1'/0'/0/0 Input amount: 129999866 Sequence Number to use (RBF opt-in enabled by default) [4294967293]: Input type (address, segwit, p2shsegwit) [segwit]:
Previous output to spend (txid:vout) []:
Output address (for non-change output) []: 2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3 Amount to spend (satoshis): 129999706
Output address (for non-change output) []: BIP-32 path (for change output) []: Transaction version [2]: Transaction locktime [0]: Please confirm action on your Trezor device.
Signed Transaction: 0200000000010100ff121dd31ead0f06...f279b642d85c48798685f86200000000 ```

Example of using crafting a TXN using trezorlib directly

If your good with python, or want to see how everything works under the hood, here's 80 lines of python to generate a similar signed transaction.
```python

!/usbin/env python3

[repo] https://github.com/brianddk/reddit ... python/offline_txn.py

[req] pip3 install trezor

from trezorlib import btc, messages as proto, tools, ui from trezorlib import MINIMUM_FIRMWARE_VERSION as min_version from trezorlib.client import TrezorClient from trezorlib.transport import get_transport from trezorlib.btc import from_json from json import loads from decimal import Decimal from sys import exit

Tested with SLIP-0014 allallall seed (slip-0014.md)

User Provided Fields; These are pulled from test scripts

CHANGE THESE!!!

coin = "Testnet"

Get legacy UTXO prev_txn hex from blockbook server. For example:

https://tbtc1.trezor.io/api/tx-specific/ \

e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00

in1_prev_txn_s = '{"txid":' \ '"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00"}'
in1_prev_index = 0 in1_addr_path = "m/84'/1'/0'/0/0" # allallall seed in1_amount = 129999867 out1_address = "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" out1_amount = in1_amount - 192

Defaults

tx_version = 2 tx_locktime = 0 sequence = 4294967293

Code

in1_prev_txn_j = loads(in1_prev_txn_s, parse_float=Decimal) in1_prev_hash = in1_prev_txn_j['txid'] in1_prev_hash_b = bytes.fromhex(in1_prev_hash) device = get_transport() client = TrezorClient(transport=device, ui=ui.ClickUI())
fw_version = (client.features.major_version, client.features.minor_version, client.features.patch_version) if fw_version < min_version[client.features.model]: print("Please flash to the latest FW") exit(1)
signtx = proto.SignTx( version = tx_version, lock_time = tx_locktime )
ins = [proto.TxInputType( address_n=tools.parse_path(in1_addr_path), prev_hash=in1_prev_hash_b, prev_index=in1_prev_index, amount=in1_amount, script_type=proto.InputScriptType.SPENDWITNESS, sequence=sequence )] outs = [proto.TxOutputType( address=out1_address, amount=out1_amount, script_type=proto.OutputScriptType.PAYTOADDRESS )]
txes = None for i in ins: if i.script_type == proto.InputScriptType.SPENDADDRESS: tx = from_json(in1_prev_txn_j) txes = {in1_prev_hash_b: tx} break
_, serialized_tx = btc.sign_tx(client, coin, ins, outs, details=signtx, prev_txes=txes) client.close() print(f'{{"hex": "{serialized_tx.hex()}"}}') ```
From here, you simple take the resultant TXN hex and import it into Electrum using the "Tools -> Load transaction -> From text" clickpath
submitted by brianddk to TREZOR [link] [comments]

Technical: More channel mechanisms!

This is a followup of my older post about the history of payment channel mechanisms.
The "modern" payment channel system is Lightning Network, which uses bidirectional indefinite-lifetime channels, using HTLCs to trustlessly route through the network.
However, at least one other payment channel mechanism was developed at roughly the same time as Lightning, and there are also further proposals that are intended to replace the core payment channel mechanism in use by Lightning.
Now, in principle, the "magic" of Lightning lies in combining two ingredients:
  1. Offchain updateable systems.
  2. HTLCs to implement atomic cross-system swaps.
We can replace the exact mechanism implementing an offchain updateable system. Secondly we can replace the use of HTLCs with another atomic cross-system swap, which is what we would do when we eventually switch to payment points and scalars from payment hashes and preimages.
So let's clarify what I'll be discussing here:
Now I might use "we" here to refer to what "we" did to the design of Bitcoin, but it is only because "we" are all Satoshi, except for Craig Steven Wright.
So, let's present the other payment channel mechanisms. But first, a digression.

Digression: the new nSequence and OP_CHECKSEQUENCEVERIFY

The new relative-timelock semantics of nSequence.
Last time we used nSequence, we had the unfortunate problem that it would be easy to rip off people by offering a higher miner fee for older state where we own more funds, then convince the other side of the channel to give us goods in exchange for a new state with tiny miner fees, then publish both the old state and the new state, then taunt the miners with "so which state is gonna earn you more fees huh huh huh?".
This problem, originally failed by Satoshi, was such a massive facepalm that, in honor of miners doing the economically-rational thing in the face of developer and user demands when given a non-final nSequence, we decided to use nSequence as a flag for the opt-in replace-by-fee.
Basically, under opt-in replace-by-fee, if a transaction had an nSequence that was not 0xFFFFFFFF or 0xFFFFFFFE, then it was opt-in RBF (BIP125). Because you'd totally abuse nSequence to bribe miners in order to steal money from your bartender, especially if your bartender is not a werebear.
Of course, using a 4-byte field for a one-bit flag (to opt-in to RBF or not) was a massive waste of space, so when people started proposing relative locktimes, the nSequence field was repurposed.
Basically, in Bitcoin as of the time of this writing (early 2020) if nSequence is less than 0x80000000 it can be interpreted as a relative timelock. I'll spare you the details here, BIP68 has them, but basically nSequence can indicate (much like nLockTime) either a "real world" relative lock time (i.e. the output must have been confirmed for X seconds before it can be spent using a transaction with a non-zero nSequence) or the actual real world, which is measured in blocks (i.e. the output must have been confirmed for N blocks before it can be spent using a transaction with a non-zero nSequence). Of course, this is the Bitcoin universe and "seconds" is a merely human delusion, so we will use blocks exclusively.
And similarly to OP_CHECKLOCKTIMEVERIFY, we also added OP_CHECKSEQUENCEVERIFY in BIP112. This ensures that the nSequence field is a relative-locktime (i.e. less than 0x80000000) and that it is the specified type (block-based or seconds-based) and that it is equal or higher to the specified minimum relative locktime.
It is important to mention the new, modern meaning of nSequence, because it is central to many of the modern payment channel mechanisms, including Lightning Poon-Dryja.
Lessons learned?

Decker-Wattenhofer "Duplex Micropayment Channels"

Mechanisms-within-mechanisms for a punishment-free bidirectional indefinite-lifetime payment channel.
The Decker-Wattenhofer paper was published in 2015, but the Poon-Dryja "Lightning Network" paper was published in 2016. However, the Decker-Wattenhofer paper mentions the Lightning mechanism, specifically mentioning the need to store every old revocation key (i.e. the problem I mentioned last time that was solved using RustyReddit shachains). Maybe Poon-Dryja presented the Lightning Network before making a final published paper in 2016, or something. Either that or cdecker is the Bitcoin time traveler.
It's a little hard to get an online copy now, but as of late 2019 this seems to work: copy
Now the interesting bit is that Decker-Wattenhofer achieves its goals by combining multiple mechanisms that are, by themselves, workable payment channel mechanisms already, except each has some massive drawbacks. By combining them, we can minimize the drawbacks.
So let's go through the individual pieces.

Indefinite-lifetime Spilman channels

As mentioned before, Spilman channels have the drawback that they have a limited lifetime: the lock time indicated in the backoff transaction or backoff branch of the script. However, instead of an absolute lock time, we can use a relative locktime.
In order to do so, we use a "kickoff" transaction, between the backoff transaction and the funding transaction. Our opening ritual goes this way, between you and our gender-neutral bartender-bancho werebear:
  1. First, you compute the txid for the funding transaction and the kickoff transaction. The funding transaction takes some of your funds and puts it into a 2-of-2 between you and the bartender, and the kickoff is a 1-input 1-output transaction that spends the funding transaction and outputs to another 2-of-2 between you and the bartender.
  2. Then, you generate the backoff transaction, which spends the kickoff transaction and returns all the funds to you. The backoff has a non-zero nSequence, indicating a delay of a number of blocks agreed between you, which is a security/convenience tradeoff parameter
  3. You sign the backoff transaction, then send it to the bartender.
  4. The bartender signs the backoff, and gives back the fully-signed transaction to you.
  5. You sign the kickoff transaction, then send it to the bartender.
  6. The bartender signs the kickoff, and gives it back to you fully signed.
  7. You sign and broadcast the funding transaction, and both of you wait for the funding transaction to be deeply confirmed.
The above setup assumes you're using SegWit, because transaction malleability fix.
At any time, either you or the bartender can broadcast the kickoff transaction, and once that is done, this indicates closure of the channel. You do this if you have drunk enough alcoholic beverages, or the bartender could do this when he or she is closing the bar.
Now, to get your drinks, you do:
  1. Sign a transaction spending the kickoff, and adding more funds to the bartender, to buy a drink. This transaction is not encumbered with an nSequence.
  2. Hand the signed transaction to the bartender, who provides you with your next drink.
The channel is closed by publishing the kickoff transaction. Both of you have a fully-signed copy of the kickoff, so either of you can initiate the close.
On closure (publication and confirmation of the kickoff transaction), there are two cases:
  1. You fail to pick up any chicks at the bar (I prefer female humans of optimum reproductive age myself rather than nestling birds, but hey, you do you) so you didn't actually spend for drinks at all. In this case, the bartender is not holding any transactions that can spend the kickoff transaction. You wait for the agreed-upon delay after the kickoff is confirmed, and then publish the backoff transaction and get back all the funds that you didn't spend.
  2. You spend all your money on chicks and end up having to be kicked into a cab to get back to your domicile, because even juvenile birds can out-drink you, you pushover. The bartender then uses the latest transaction you gave (the one that gives the most money to him or her --- it would be foolish of him or her to use an earlier version with less money!), signs it, and broadcasts it to get his or her share of the money from the kickoff transaction.

Decrementing nSequence channels

Enforcing order by reducing relative locktimes.
I believe this to be novel to the Decker-Wattenhofer mechanism, though I might be missing some predecessor.
This again uses the new relative-locktime meaning of nSequence. As such, it also uses a kickoff transaction like the above indefinite-lifetime Spilman channel. Set up is very similar to the setup of the above indefinite-lifetime Spilman channel, except that because this is bidirectional, we can actually have both sides put money into the initial starting backoff transaction.
We also rename the "backoff" transaction to "state" transaction. Basically, the state transaction indicates how the money in the channel is divided up between the two participants. The "backoff" we sign during the funding ritual is now the first state transaction. Both sides keep track of the current state transaction (which is initialized to the first state transaction on channel establishment).
Finally, the starting nSequence of the first state transaction is very large (usually in the dozens or low hundreds of blocks).
Suppose one participant wants to pay the other. The ritual done is then:
  1. A new version of the current state transaction is created with more money in the payee side.
  2. This new version has nSequence that is one block lower than the current state transaction (in practice it should be a few blocks lower, not just one, because sometimes miners find blocks in quick succession).
  3. Both sides exchange signatures for the new state transaction.
  4. Both sides set the new state transaction as the current state transaction that will be the basis for the next payment.
When the channel is closed by publication of the kickoff transaction, then the transaction with the lowest nSequence becomes valid earlier than the other state transactions. This is enough to enforce that the most recent state transaction (the one with the lowest nSequence, and thus the first to become valid) is published.

Mechanism-within-mechanism

Combining the ingredients of the Decker-Wattenhofer Duplex Micropayment Channels concoction.
Of note is that we can "chain" these mechanisms together in such a way that we strengthen their strengths while covering their weaknesses.
A note is that both the indefinite-lifetime nSequence Spilman variant, and the above decrementing nSequence mechanism, both have "kickoff" transactions.
However, when we chain the two mechanisms together, it turns out that the final transaction of one mechanism also serves as the kickoff of the next mechanism in the chain.
So for example, let's chain two of those decrementing nSequence channels together. Let's make them 144 blocks maximum delay each, and decrement in units of 4 blocks, so each of the chained mechanisms can do 37 updates each.
We start up a new channel with the following transactions:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 144, paying to the initial state of the channel.
When we update this channel, we first update the "stage 2" state transaction, replacing it with an nSequence lower by 4 blocks. So after one update our transactions are:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 140, paying to the second state of the channel.
The first 3 transactions are the same, only the last one is replaced with a state transaction with lower `nSequence.
Things become interesting when we reach the "stage 2" having nSequence 0. On the next update, we create a new "stage 1", with an nSequence that is 4 lower, and "reset" the "stage 2" back to an nSequence of 144.
This is safe because even though we have a "stage 2" with shorter nSequence, that stage 2 spends a stage 1 with an nSequence of 144, and the stage 1 with nSequence of 140 would beat it to the blockchain first.
This results in us having, not 36 + 36 updates, but instead 36 * 36 updates (1296 updates). 1296 updates is still kinda piddling, but that's much better than just a single-stage decrementing nSequence channel.
The number of stages can be extended indefinitely, and your only drawback would be the amount of blockchain space you'd spend for a unilateral close. Mutual cooperative closes can always shortcut the entire stack of staged transactions and cut it to a single mutual cooperative close transaction.
But that's not all! You might be wondering about the term "duplex" in the name "Duplex Micropayment Channels".
That's because the last decrementing nSequence stage does not hold the money of the participants directly. Instead, the last stage holds two indefinite-lifetime Spilman channels. As you might remember, Spilman channels are unidirectional, so the two Spilman channels represent both directions of the channel. Thus, duplex.
Let's go back to you and your favorite werebear bartender. If you were using a Decker-Wattenhofer Duplex Micropayment Channel, you'd have several stages of decrementing nSequence, terminated in two Spilman channels, a you-to-bartender channel and a bartender-to-you channel.
Suppose that, while drinking, the bartender offers you a rebate on each drink if you do some particular service for him or her. Let us not discuss what service this is and leave it to your imagination. So you pay for a drink, decide you want to get the rebate, and perform a service that the bartender finds enjoyable. So you transfer some funds on the you-to-bartender direction, and then later the bartender transfers some funds in the bartender-to-you channel after greatly enjoying your service.
Suppose you now exhaust the you-to-bartender direction. However, you note that the rebates you've earned are enough to buy a few more drinks. What you do instead is to update the staged decrementing nSequence mechanisms, and recreate the two Spilman directions such that the you-to-bartender direction contains all your current funds and the bartender-to-you direction contains all the bartender's funds. With this, you are now able to spend even the money you earned from rebates. At the same time, even if the staged decrementing nSequence mechanisms only have a few hundred thousand updates, you can still extend the practical number of updates as long as you don't have to reset the Spilman channels too often.

Burchert-Decker-Wattenhofer Channel Factories

Because you like channels so much, you put channels inside channels so you could pay while you pay. I N C E P T I O N
The Decker-Wattenhofer Duplex Micropayment Channels introduced the possibility of nesting a channel mechanism inside another channel mechanism. For example, it suggests nesting a decrementing-nSequence mechanism inside another decrementing-nSequence mechanism, and having as well an unlimited-lifetime Spilman channel at the end. In the Decker-Wattenhofer case, it is used to support the weakness of one mechanism with the strength of another mechanism.
One thing to note is that while the unlimited-lifetime Spilman channel variant used is inherently two-participant (there is one payer and one payee), the decrementing-nSequence channel mechanism can be multiparticipant.
Another thing of note is that nothing prevents one mechanism from hosting just one inner mechanism, just as it is perfectly fine for a Lightning Network channel to have multiple HTLCs in-flight, plus the money in your side, plus the money in the counterparty's side. As these are "just" Bitcoin-enforceable contracts, there is no fundamental difference between an HTLC, and a payment channel mechanism.
Thus the most basic idea of the Burchert-Decker-Wattenhofer Channel Factories paper is simply that we can have a multiparticipant update mechanism host multiple two-party update mechanisms. The outer multiparticipant update mechanism is called a "channel factory" while the inner two-party update mechanisms are called "channels".
The exact mechanism used in the Burchert-Decker-Wattenhofer paper uses several decrementing-nSequence mechanisms to implement the factory, and Decker-Wattenhofer Duplex Micropayment Channels to implement the channel layer.
However, as noted before, there is no fundamental difference between a Poon-Dryja channel and an HTLC. So it is in fact possible to have chained Decker-Wattenhofer decrementing-nSequence mechanisms to implement the factory level, while the channels are simply Poon-Dryja channels.

Conclusion

So this concludes for now an alternative mechanism to the classic Poon-Dryja that Lightning uses. The tradeoffs are significantly different between Decker-Wattenhofer vs Poon-Dryja:

Copyright

Copyright 2020 Alan Manuel K. Gloria. Released under CC-BY.
submitted by almkglor to Bitcoin [link] [comments]

Craig Steven Wright is Satoshi Nakamoto

A couple of years ago in the early months of the 2017, I published a piece called Abundance Via Cryptocurrencies (https://www.reddit.com/C\_S\_T/comments/69d12a/abundance\_via\_cryptocurrencies/) in which I kind of foresaw the crypto boom that had bitcoin go from $1k to $21k and the alt-coin economy swell up to have more than 60% of the bitcoin market capitalisation. At the time, I spoke of coming out from “the Pit” of conspiracy research and that I was a bit suss on bitcoin’s inception story. At the time I really didn’t see the scaling solution being put forward as being satisfactory and the progress on bitcoin seemed stifled by the politics of the social consensus on an open source protocol so I was looking into alt coins that I thought could perhaps improve upon the shortcomings of bitcoin. In the thread I made someone recommended to have a look at 4chan’s business and finance board. I did end up taking a look at it just as the bull market started to really surge. I found myself in a sea of anonymous posters who threw out all kinds of info and memes about the hundreds, thousands, tens of thousands of different shitcoins and why they’re all going to have lambos on the moon. I got right in to it, I loved the idea of filtering through all the shitposts and finding the nuggest of truth amongst it all and was deeply immersed in it all as the price of bitcoin surged 20x and alt coins surged 5-10 times against bitcoin themselves. This meant there were many people who chucked in a few grand and bought a stash of alt coins that they thought were gonna be the next big thing and some people ended up with “portfolios” 100-1000x times their initial investment.
To explain what it’s like to be on an anonymous business and finance board populated with incel neets, nazis, capitalist shit posters, autistic geniuses and whoever the hell else was using the board for shilling their coins during a 100x run up is impossible. It’s hilarious, dark, absurd, exciting and ultimately addictive as fuck. You have this app called blockfolio that you check every couple of minutes to see the little green percentages and the neat graphs of your value in dollars or bitcoin over day, week, month or year. Despite my years in the pit researching conspiracy, and my being suss on bitcoin in general I wasn’t anywhere near as distrustful as I should have been of an anonymous business and finance board and although I do genuinely think there are good people out there who are sharing information with one another in good faith and feel very grateful to the anons that have taken their time to write up quality content to educate people they don’t know, I wasn’t really prepared for the level of organisation and sophistication of the efforts groups would go to to deceive in this space.
Over the course of my time in there I watched my portfolio grow to ridiculous numbers relative to what I put in but I could never really bring myself to sell at the top of a pump as I always felt I had done my research on a coin and wanted to hold it for a long time so why would I sell? After some time though I would read about something new or I would find out of dodgy relationships of a coin I had and would want to exit my position and then I would rebalance my portfolio in to a coin I thought was either technologically superior or didn’t have the nefarious connections to people I had come across doing conspiracy research. Because I had been right in to the conspiracy and the decentralisation tropes I guess I always carried a bit of an antiauthoritarian/anarchist bias and despite participating in a ridiculously capitalistic market, was kind of against capitalism and looking to a blockchain protocol to support something along the lines of an open source anarchosyndicalist cryptocommune. I told myself I was investing in the tech and believed in the collective endeavour of the open source project and ultimately had faith some mysterious “they” would develop a protocol that would emancipate us from this debt slavery complex.
As I became more and more aware of how to spot artificial discussion on the chans, I began to seek out further some of the radical projects like vtorrent and skycoin and I guess became a bit carried away from being amidst such ridiculous overt shilling as on the boards so that if you look in my post history you can even see me promoting some of these coins to communities I thought might be sympathetic to their use case. I didn’t see it at the time because I always thought I was holding the coins with the best tech and wanted to ride them up as an investor who believed in them, but this kind of promotion is ultimately just part of a mentality that’s pervasive to the cryptocurrency “community” that insists because it is a decentralised project you have to in a way volunteer to inform people about the coin since the more decentralised ones without premines or DAO structures don’t have marketing budgets, or don’t have marketing teams. In the guise of cultivating a community, groups form together on social media platforms like slack, discord, telegram, twitter and ‘vote’ for different proposals, donate funds to various boards/foundations that are set up to give a “roadmap” for the coins path to greatness and organise marketing efforts on places like reddit, the chans, twitter. That’s for the more grass roots ones at least, there are many that were started as a fork of another coin, or a ICO, airdrop or all these different ways of disseminating a new cryptocurrency or raising funding for promising to develop one. Imagine the operations that can be run by a team that raised millions, hundreds of millions or even billions of dollars on their ICOs, especially if they are working in conjunction with a new niche of cryptocurrency media that’s all nepotistic and incestuous.
About a year and a half ago I published another piece called “Bitcoin is about to be dethroned” (https://www.reddit.com/C\_S\_T/comments/7ewmuu/bitcoin\_is\_about\_to\_be\_dethroned/) where I felt I had come to realise the scaling debate had been corrupted by a company called Blockstream and they had been paying for social media operations in a fashion not to dissimilar to correct the record or such to control the narrative around the scaling debate and then through deceit and manipulation curated an apparent consensus around their narrative and hijacked the bitcoin name and ticker (BTC). I read the post again just before posting this and decided to refer to it to to add some kind of continuity to my story and hopefully save me writing so much out. Looking back on something you wrote is always a bit cringey especially because I can see that although I had made it a premise post, I was acting pretty confident that I was right and my tongue was acidic because of so much combating of shills on /biz/ but despite the fact I was wrong about the timing I stand by much of what I wrote then and want to expand upon it a bit more now.
The fork of the bitcoin protocol in to bitcoin core (BTC) and bitcoin cash (BCH) is the biggest value fork of the many that have occurred. There were a few others that forked off from the core chain that haven’t had any kind of attention put on them, positive or negative and I guess just keep chugging away as their own implementation. The bitcoin cash chain was supposed to be the camp that backed on chain scaling in the debate, but it turned out not everyone was entirely on board with that and some players/hashpower felt it was better to do a layer two type solution themselves although with bigger blocks servicing the second layer. Throughout what was now emerging as a debate within the BCH camp, Craig Wright and Calvin Ayre of Coin Geek said they were going to support massive on chain scaling, do a node implementation that would aim to restore bitcoin back to the 0.1.0 release which had all kinds of functionality included in it that had later been stripped by Core developers over the years and plan to bankrupt the people from Core who changed their mind on agreeing with on-chain scaling. This lead to a fork off the BCH chain in to bitcoin satoshis vision (BSV) and bitcoin cash ABC.

https://bitstagram.bitdb.network/m/raw/cbb50c322a2a89f3c627e1680a3f40d4ad3cee5a3fb153e5d6d001bdf85de404

The premise for this post is that Craig S Wright was Satoshi Nakamoto. It’s an interesting premise because depending upon your frame of reference the premise may either be a fact or to some too outrageous to even believe as a premise. Yesterday it was announced via CoinGeek that Craig Steven Wright has been granted the copyright claim for both the bitcoin white-paper under the pen name Satoshi Nakamoto and the original 0.1.0 bitcoin software (both of which were marked (c) copyright of satoshi nakamoto. The reactions to the news can kind of be classified in to four different reactions. Those who heard it and rejected it, those who heard it but remained undecided, those who heard it and accepted it, and those who already believed he was. Apparently to many the price was unexpected and such a revelation wasn’t exactly priced in to the market with the price immediately pumping nearly 100% upon the news breaking. However, to some others it was a vindication of something they already believed. This is an interesting phenomena to observe. For many years now I have always occupied a somewhat positively contrarian position to the default narrative put forward to things so it’s not entirely surprising that I find myself in a camp that holds the minority opinion. As you can see in the bitcoin dethroned piece I called Craig fake satoshi, but over the last year and bit I investigated the story around Craig and came to my conclusion that I believed him to be at least a major part of a team of people who worked on the protocol I have to admit that through reading his articles, I have kind of been brought full circle to where my contrarian opinion has me becoming somewhat of an advocate for “the system’.
https://coingeek.com/bitcoin-creator-craig-s-wright-satoshi-nakamoto-granted-us-copyright-registrations-for-bitcoin-white-paper-and-code/

When the news dropped, many took to social media to see what everyone was saying about it. On /biz/ a barrage of threads popped up discussing it with many celebrating and many rejecting the significance of such a copyright claim being granted. Immediately in nearly every thread there was a posting of an image of a person from twitter claiming that registering for copyright is an easy process that’s granted automatically unless challenged and so it doesn’t mean anything. This was enough for many to convince them of the insignificance of the revelation because of the comment from a person who claimed to have authority on twitter. Others chimed in to add that in fact there was a review of the copyright registration especially in high profile instances and these reviewers were satisfied with the evidence provided by Craig for the claim. At the moment Craig is being sued by Ira Kleiman for an amount of bitcoin that he believes he is entitled to because of Craig and Ira’s brother Dave working together on bitcoin. He is also engaged in suing a number of people from the cryptocurrency community for libel and defamation after they continued to use their social media/influencer positions to call him a fraud and a liar. He also has a number of patents lodged through his company nChain that are related to blockchain technologies. This has many people up in arms because in their mind Satoshi was part of a cypherpunk movement, wanted anonymity, endorsed what they believed to be an anti state and open source technologies and would use cryptography rather than court to prove his identity and would have no interest in patents.
https://bitstagram.bitdb.network/m/raw/1fce34a7004759f8db16b2ae9678e9c6db434ff2e399f59b5a537f72eff2c1a1
https://imgur.com/a/aANAsL3)

If you listen to Craig with an open mind, what cannot be denied is the man is bloody smart. Whether he is honest or not is up to you to decide, but personally I try to give everyone the benefit of the doubt and then cut them off if i find them to be dishonest. What I haven’t really been able to do with my investigation of craig is cut him off. There have been many moments where I disagree with what he has had to say but I don’t think people having an opinion about something that I believe to be incorrect is the same as being a dishonest person. It’s very important to distinguish the two and if you are unable to do so there is a very real risk of you projecting expectations or ideals upon someone based off your ideas of who they are. Many times if someone is telling the truth but you don’t understand it, instead of acknowledging you don’t understand it, you label them as being stupid or dishonest. I think that has happened to an extreme extent with Craig. Let’s take for example the moment when someone in the slack channel asked Craig if he had had his IQ tested and what it was. Craig replied with 179. The vast majority of people on the internet have heard someone quote their IQ before in an argument or the IQ of others and to hear someone say such a score that is actually 6 standard deviations away from the mean score (so probably something like 1/100 000) immediately makes them reject it on the grounds of probability. Craig admits that he’s not the best with people and having worked with/taught many high functioning people (sometimes on the spectrum perhaps) on complex anatomical and physiological systems I have seen some that also share the same difficulties in relating to people and reconciling their genius and understandings with more average intelligences. Before rejecting his claim outright because we don’t understand much of what he says, it would be prudent to first check is there any evidence that may lend support to his claim of a one in a million intelligence quotient.

Craig has mentioned on a number of occasions that he holds a number of different degrees and certifications in relation to law, cryptography, statistics, mathematics, economics, theology, computer science, information technology/security. I guess that does sound like something someone with an extremely high intelligence could achieve. Now I haven’t validated all of them but from a simple check on Charles Sturt’s alumni portal using his birthday of 23rd of October 1970 we can see that he does in fact have 3 Masters and a PhD from Charles Sturt. Other pictures I have seen from his office at nChain have degrees in frames on the wall and a developer published a video titled Craig Wright is a Genius with 17 degrees where he went and validated at least 8 of them I believe. He is recently publishing his Doctorate of Theology through an on-chain social media page that you have to pay a little bit for access to sections of his thesis. It’s titled the gnarled roots of creation. He has also mentioned on a number of occasions his vast industry experience as both a security contractor and business owner. An archive from his LinkedIn can be seen below as well.

LinkedIn - https://archive.is/Q66Gl
https://youtu.be/nXdkczX5mR0 - Craig Wright is a Genius with 17 Degrees
https://www.yours.org/content/gnarled-roots-of-a-creation-mythos-45e69558fae0 - Gnarled Roots of Creation.
In fact here is an on chain collection of articles and videos relating to Craig called the library of craig - https://www.bitpaste.app/tx/94b361b205196560d1bd09e4e3b3ec7ad6bea478af204cabfe243efd8fc944dd


So there is a guy with 17 degrees, a self professed one in a hundred thousand IQ, who’s worked for Australian Federal Police, ASIO, NSA, NASA, ASX. He’s been in Royal Australian Air Force, operated a number of businesses in Australia, published half a dozen academic papers on networks, cryptography, security, taught machine learning and digital forensics at a number of universities and then another few hundred short articles on medium about his work in these various domains, has filed allegedly 700 patents on blockchain related technology that he is going to release on bitcoin sv, copyrighted the name so that he may prevent other competing protocols from using the brand name, that is telling you he is the guy that invented the technology that he has a whole host of other circumstantial evidence to support that, but people won’t believe that because they saw something that a talking head on twitter posted or that a Core Developer said, or a random document that appears online with a C S Wright signature on it that lists access to an address that is actually related to Roger Ver, that’s enough to write him off as a scam. Even then when he publishes a photo of the paper copy which appears to supersede the scanned one, people still don’t readjust their positions on the matter and resort back to “all he has to do is move the coins or sign a tx”.

https://imgur.com/urJbe10

Yes Craig was on the Cypherpunk mailing list back in the day, but that doesn’t mean that he was or is an anarchist. Or that he shares the same ideas that Code Is Law that many from the crypto community like to espouse. I myself have definitely been someone to parrot the phrase myself before reading lots of Craig’s articles and trying to understand where he is coming from. What I have come to learn from listening and reading the man, is that although I might be fed up with the systems we have in place, they still exist to perform important functions within society and because of that the tools we develop to serve us have to exist within that preexisting legal and social framework in order for them to have any chance at achieving global success in replacing fiat money with the first mathematically provably scarce commodity. He says he designed bitcoin to be an immutable data ledger where everyone is forced to be honest, and economically disincentivised to perform attacks within the network because of the logs kept in a Write Once Read Many (WORM) ledger with hierarchical cryptographic keys. In doing so you eliminate 99% of cyber crime, create transparent DAO type organisations that can be audited and fully compliant with legislature that’s developed by policy that comes from direct democratic voting software. Everyone who wants anonymous coins wants to have them so they can do dishonest things, illegal things, buy drugs, launder money, avoid taxes.

Now this triggers me a fair bit as someone who has bought drugs online, who probably hasn’t paid enough tax, who has done illegal things contemplating what it means to have that kind of an evidence ledger, and contemplate a reality where there are anonymous cryptocurrencies, where massive corporations continue to be able to avoid taxes, or where methamphetamine can be sold by the tonne, or where people can be bought and sold. This is the reality of creating technologies that can enable and empower criminals. I know some criminals and regard them as very good friends, but I know there are some criminals that I do not wish to know at all. I know there are people that do horrific things in the world and I know that something that makes it easier for them is having access to funds or the ability to move money around without being detected. I know arms, drugs and people are some of the biggest markets in the world, I know there is more than $50 trillion dollars siphoned in to off shore tax havens from the value generated as the product of human creativity in the economy and how much human charity is squandered through the NGO apparatus. I could go on and on about the crappy things happening in the world but I can also imagine them getting a lot worse with an anonymous cryptocurrency. Not to say that I don’t think there shouldn’t be an anonymous cryptocurrency. If someone makes one that works, they make one that works. Maybe they get to exist for a little while as a honeypot or if they can operate outside the law successfully longer, but bitcoin itself shouldn’t be one. There should be something a level playing field for honest people to interact with sound money. And if they operate within the law, then they will have more than adequate privacy, just they will leave immutable evidence for every transaction that can be used as evidence to build a case against you committing a crime.

His claim is that all the people that are protesting the loudest about him being Satoshi are all the people that are engaged in dishonest business or that have a vested interest in there not being one singular global ledger but rather a whole myriad of alternative currencies that can be pumped and dumped against one another, have all kinds of financial instruments applied to them like futures and then have these exchanges and custodial services not doing any Know Your Customer (KYC) or Anti Money Laundering (AML) processes. Bitcoin SV was delisted by a number of exchanges recently after Craig launched legal action at some twitter crypto influencetalking heads who had continued to call him a fraud and then didn’t back down when the CEO of one of the biggest crypto exchanges told him to drop the case or he would delist his coin. The trolls of twitter all chimed in in support of those who have now been served with papers for defamation and libel and Craig even put out a bitcoin reward for a DOX on one of the people who had been particularly abusive to him on twitter. A big european exchange then conducted a twitter poll to determine whether or not BSV should be delisted as either (yes, it’s toxic or no) and when a few hundred votes were in favour of delisting it (which can be bought for a couple of bucks/100 votes). Shortly after Craig was delisted, news began to break of a US dollar stable coin called USDT potentially not being fully solvent for it’s apparent 1:1 backing of the token to dollars in the bank. Binance suffered an alleged exchange hack with 7000 BTC “stolen” and the site suspending withdrawals and deposits for a week. Binance holds 800m USDT for their US dollar markets and immediately once the deposits and withdrawals were suspended there was a massive pump for BTC in the USDT markets as people sought to exit their potentially not 1:1 backed token for bitcoin. The CEO of this exchange has the business registered out of Malta, no physical premises, the CEO stays hotel room to hotel room around the world, has all kind of trading competitions and the binance launchpad, uses an unregistered security to collect fees ($450m during the bear market) from the trading of the hundreds of coins that it lists on its exchange and has no regard for AML and KYC laws. Craig said he himself was able to create 100 gmail accounts in a day and create binance accounts with each of those gmail accounts and from the same wallet, deposit and withdraw 1 bitcoin into each of those in one day ($8000 x 100) without facing any restrictions or triggering any alerts or such.
This post could ramble on for ever and ever exposing the complexities of the rabbit hole but I wanted to offer some perspective on what’s been happening in the space. What is being built on the bitcoin SV blockchain is something that I can only partially comprehend but even from my limited understanding of what it is to become, I can see that the entirety of the crypto community is extremely threatened as it renders all the various alt coins and alt coin exchanges obsolete. It makes criminals play by the rules, it removes any power from the developer groups and turns the blockchain and the miners in to economies of scale where the blockchain acts as a serverless database, the miners provide computational resources/storage/RAM and you interact with a virtual machine through a monitor and keyboard plugged in to an ethernet port. It will be like something that takes us from a type 0 to a type 1 civilisation. There are many that like to keep us in the quagmire of corruption and criminality as it lines their pockets. Much much more can be read about the Cartel in crypto in the archive below. Is it possible this cartel has the resources to mount such a successful psychological operation on the cryptocurrency community that they manage to convince everyone that Craig is the bad guy, when he’s the only one calling for regulation, the application of the law, the storage of immutable records onchain to comply with banking secrecy laws, for Global Sound Money?

https://archive.fo/lk1lH#selection-3671.46-3671.55

Please note, where possible, images were uploaded onto the bitcoin sv blockchain through bitstagram paying about 10c a pop. If I wished I could then use an application etch and archive this post to the chain to be immutably stored. If this publishing forum was on chain too it would mean that when I do the archive the images that are in the bitstragram links (but stored in the bitcoin blockchain/database already) could be referenced in the archive by their txid so that they don’t have to be stored again and thus bringing the cost of the archive down to only the html and css.
submitted by whipnil to C_S_T [link] [comments]

Blockchain - How To Verify A Bitcoin Transaction And Get ... Bittrex Bitcoin Withdrawal Transaction ID TXID. New GPU Virtual 1 Bitcoin Miner Cloud Mining Automatic 100% transparent withdrawals. How to Find a Bitcoin Transaction ID in Your Coinbase ... Bitcoin: How to Create a Raw Transaction - YouTube

Breaking News. Mexikanische Steuerfahndung: Banken sind ein Risiko für Geldwäsche; Hacker stehlen 16 Millionen Dollar an Bitcoin über alte Software in Wallet; Mit dieser Strategie kann jeder ein erfolgreicher Bitcoin-Investor werden; Bitcoin muss dieses Wochenende zwischen 10.000 und 13.000 Dollar wählen Whether you pay in Bitcoin, Ethereum, Litecoin or Dash; often times the merchant will ask you for the hash or the transaction ID as a proof of payment. There are other scenarios as well where a third party wallet service or a trading platform will require you to send the transaction hash ID in order to troubleshoot any issues that you have. So how to locate this Tx Hash / TxID? But first of ... TxID Meaning. Tx Hash is the hash of the transaction. It is also known as the Transaction ID (TxID). It consists of alphanumeric characters and represents the identification number specified for the Bitcoin transaction.. Every transaction that takes place on the Bitcoin blockchain has this unique identifier. TXID can be displayed right away in a cryptocurrency wallet when a particular transaction is carried out by a user. In addition, you can find TXID using the services mentioned above. To do this, you will need a sender's cryptocurrency wallet address. For example, on blockchain.com it should be entered in the search box. The service will then show all transactions sent from this particular ... Have you just completed your first (or maybe not the first) cryptocurrency transaction in Bitcoin, Ethereum, XRP, or any other currency? Suddenly, the recipient asks you to send him a TxID? Usually, this incomprehensible term is requested to send as proof of payment. So what is TxID, and how can ...

[index] [45586] [41380] [7396] [17996] [49427] [25804] [38157] [38569] [50413] [21943]

Blockchain - How To Verify A Bitcoin Transaction And Get ...

Bittrex Bitcoin Withdrawal Transaction ID TXID. Bittrex Bitcoin Withdrawal Transaction ID TXID. Bittrex Bitcoin Withdrawal Transaction ID TXID. Http://bitcoi... How To Speed Up Txid in bitcoin 👍 Get 10 bucks FREE when with new sign up and buy $100 dollars of Bitcoin CryptoCurrency: https://www.coinbase.com/join/52199... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. #Bitcoin breakout or fake-out? $BTC pumps 10% with lower volume, $BTC still on track for $200k, ETF approval speculation, Bitconnect 2.0, HitBTC shady KYC, $... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

#