text:
What actually happens in a basic DAO in ethereum?
I've had a look at the white paper but I fail to understand exactly what is happening on the code shown on the page.
As far as I understand this example manages shareholders. But, is it possible to store organisation data somewhere? I (honestly) don't understand this.

You will find more information in the forums of the ethereum site.

Please provide sufficient information that the question can be understood from the question's text. Please, don't make us read another resource in order to be able to understand your question, but rather provide a link additionally as the source in case somebody wants to get more background information.

That's a pretty general contract: As long as more than two thirds of the shareholders agree, you can change every single storage entry. This enables to add or remove shareholders, change the program itself (as it's part of the storage as well), and store arbitrary additional data.

To extend the description in the white paper a little, here's how a voting could look like:
1) One shareholder proposes a change of some storage bytes using the second transaction type ([1,k,L,v0,v1...vn]). k is a kind of ID to refer to this suggestion later, L is the first storage address that will be changed and v0, v1, ... is the data to store. As you can see, arbitrary changes of storage entries are allowed.
2) Now, the other shareholders can vote to implement the change with the first transaction type ([0,k], where k refers to the previously registered proposal). The number of votes in favor of this proposal is stored at a storage location given by the hash of k.
3) As soon as enough votes have been received, a shareholder can send the third transaction type to apply proposal k, i.e. write the data to the storage.


text:
Is Vertcoin really ASIC resistant?
Vertcoin comes with Adaptive-N-factor, which means the scrypt algorithm PBKDF parameter N will be changed according to the announced time table. Litecoin has N=10, while Vertcoin starts with N=11. And they claim the adaptive-N will resist the ASIC miner.
To produce an ASIC produce, it will need a huge amount of initial cost because of the prototyping (FPGA), HDL design, emulation, synthesis and layout, wafer fabrication, packing, and testing.
However, scrypt ASIC is now a real product (no matter how much it costs now). So re-target it to another new parameter should be not too difficult. I mean the whole architecture does not change (PBKDF is the same; only some parameters change, such as memory size and N), so the new ASIC development won't need to be started from the scratch up, such that cost is relative smaller than the initial product started from ground zero. Moreover, at the time of N adjustment at Jan 2016, the transistor size will be smaller and memory speed will be much higher, new technology will also enable the realization of the new ASIC miners for the new N factors.
If CPU/GPU can do the scrypt adaptive-N-factor algorithm at that time, I can say ASIC can also do that if there is a market and lots of demands. My idea is that, if vertcoin is very profitable (like or surpass BTC), Those ASIC company would also love to produce their ASIC miners with new N-factor. They could produce scrypt N=12 miner ready for the N-factor changes at Jan 2016, and announce for the pre-sale 3 or 6 months ago.
To me, adaptive-N-factor is just like one of BTC difficulty things. No one is mining BTC with miners whose hashrate is MHs or 10GHs or below, although all BTC miners are using the same proof-of-work algorithm SHA.

The primary limiting factor is memory. As N increases, memory starts to become the most expensive component, whether's it's in a GPU or an ASIC. For example, let's say the memory needed to achieve a certain level of parallelization costs $800. Now a GPU chip costs $400, while an ASIC chip costs $100. So the GPU costs $1,200 overall while the ASIC costs $900. This represents only 25% cost savings, making people hesitant to buy a device which is useful for only one task and thus may be worthless in a few years (if GPU mining becomes unprofitable, they could always offload the GPU at half price or more to gamers).

To me, adaptive-N-factor is just like one of BTC difficulty things. No one is mining BTC with miners whose hashrate is MHs or 10GHs or below, although all BTC miners are using the same proof-of-work algorithm SHA.

Not true. Difficulty is a very simple parameter that does not affect the computations done; it merely is a threshold for determining which hashes are in and which are out. The N-factor actually affects the running of the Scrypt-N algorithm.

Flowertechnology is releasing 3 asic miners which can mine the new "scrypt-n" algorythm 1. july... It's been on pre-order for some time

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Looking for nonces of even numbers
Each one of bitcoin and its derived crypto-currencies has a nonce value in the block, no matter what the algorithm is. Every miner tries to search for a luck nonce which can make the hash value smaller than the target under the required difficulty.
However, recently I search scrypt based cryptocurrencies, like the dogecoin and vertcoin block chain for few blocks. I found most of the nonce are even numbers, except for (only manually browsed in block explorer)
Block #184161 - nonce = 8dce5c01
Block #184143 - nonce = 2a674001
Block #184139 - nonce = 930aa899
many other blocks from the latest block (Block #184174) and blocks in between of them are even numbers. Moreover, many nonce value are in hex number of form XXXXXX00 (in an integer hex number form, it is stored as 00XXXXXX in block), or multiples of 256.
The same outcome I observed in Vertcoin blocks. I manually traversed for few blocks and also found nonces of them are also even numbers.
I'd like to ask a question. If I configure the scrypt or n-scrypt to search only even numbers, is it possible to have higher chance to find the nonce which can solve the current quickly?
BTW, I won't expect the mining revenue of each miner in the pool (PPS or PPLNS) is going to be greater than that of normal nonce searching algorithm because the pool count for "shares" you found. When you skip odd numbers, you also lose the chance to get a share (solved by the odd nonce) which can meet the diff the pool gives to you. However, when a pool found a nonce that can solve the block, then the pool wins and gets the rewards.

Edited: Apr 18
I wrote a small program to collect some statistical data. From recent Dogecoin block #186,299 to #145,000 (the last mandatory update)
total 41,300 blocks

number of odds = 3,891  (9.42%)
number of evens = 37,409 (90.58%)

ratio of odd to even is about 1:10

Among the evens, the number of multiples of 256 = 35,106

85% of total
93.866% of evens

Update: 4/20
I recently also checked the nonces from block 552,780 to 253,898 of Litecoin.
totally 298,883 blocks.

number of odds = 42,963 (14.374521%)
number of evens = 255,920 (85.625479%)
Among the evens, the number of multiples of 256 = 225,746

75.529890% of total

Update: 4/21
I use a small Perl script and call litecoind/dogecoind wallet to print out each block's nonce. It is very slow but quite simple. It would be very fast when you are using binary block database parser.
#!/usr/bin/perl -w

my $odd = 0;
my $even = 0;
my $m256 = 0;
my $total = 0;
for ($i = 186299; $i >= 145000; $i = $i-1) {
    $nonce = `dogecoind getblock \`dogecoind getblockhash $i\` | grep nonce`;
    chomp $nonce;
    $nonce =~ s/[^0-9]*//g;
    printf "%d %d\n", $i, $nonce;

    if (($nonce %2)== 1) {
            $odd++;
    }
    else {
            $even = $even + 1;
            $m256++ if (($nonce % 256) == 0);
    }
    $total ++;
}
printf "odds=%d (%f%%) evens=%d (%f%%) 256s=%d (%f%%)\n",
     $odd, (100.0*$odd/$total),
     $even, (100.0*$even/$total),
     $m256, 100.0*$m256/$total;

Every nonce has the same chance of solving a block or share. Using only even nonces will not change your odds at all. It could be that some mining software prefers to try even nonce values; perhaps it's more efficient on certain hardware or something.

Yes, every odd or even number has the same probability to solve the block. However, the race game is that if your pool find a nonce solution earlier than other pool or others (solo), you win the round. Moreover, I don't think it is more efficient on certain hardware because only the nonce can be altered, the SHA and scrypt core algorithm could not be changed, every bit counts.

I agree with @NateEldredge here. Also looking at an other scrypt based altcoin, Litcoin, I saw no significant difference between the occurrences of even and odd nonces. It seems to be related to Dodgecoin, not to the hashing algorithm in use. However, it would be interesting to know why the nonce values take this shape in Dodgecoin. Dodgecoin.

I get similar statistical data among LTC and DOGE, (even Vertcoin). Don't known the reason but looks very interesting.

It would probably be pretty easy to perform a controlled test at low difficulty. If even nonces really are significantly more successful it would suggest a weakness in scrypt.

Would you be willing to share the code that gathered your data?

@NateEldredge, please see my latest update. Just a small perl to retrieve block nonces.

At this point, I believe your seemingly innocent question deserves an full-blown investigation, publishing its partial results in a blog, or even (should you polish them) in a journal. If the disparity holds true for other scrypt-based coins, you might have spotted a vulnerability or a nice way to increase profitability of miners! As Nate suggested, might be worth testing in an isolated, small network. Have you checked for SHA-256 based coins? Where can I tip you for your efforts?

Thanks for your suggestion, @JoePineda. Yes, I'm also conducting a small experiment. I didn't checked for SHA-256 based coins because I quickly browsed through few blocks of bitcoin and didn't see any regular patterns. When I checked Dogecoin block-chain, I noticed that even numbers appears more often, and in a block explorer, it shows the nonce in hex number so I noticed that so many nonces are multiplies of 256. And you can see my profile for the details. Thanks!

There is one variable that you are not considering however, if I was mining I would be right on this. The variable is the transactions that are included in the block, which is always random.

That's why I should test this on public p2p network, not a small and closed test-net. Moreover, the nonces found in the article are retrieved from existing public scrypt-based cryptocoins, no matter the number of transactions in each block is only few numbers or few dozens of transactions.

Note that depending on endianness, "multiples of 256" == "small enough that I only bothered to fill in 3 bytes, not all 4"

I see your point. The getwork protocol provides data in little endian. Check LTC block 100000 , http://goo.gl/w0UWpx, and https://litecoin.info/Block_hashing_algorithm, the decimal number 2147586629, or 0x80019245 in hex, and is stored as 0x45,0x92,0x01,0x80 in little endian in block. The nonce you see either in the blockchain web or wallet (getblock method) are converted to host endian to show the 32-bit number (x86 is also little endian, so no convert need). That means all multiples of 256, which is in the form of XXXXXX00 in hex, are stored as "00XXXXXX" in the block.

I think that Tim S. may have the answer with his comment about endian-ness.
Your observations about the nonce having its lowest byte zero (being a multiple of 256), are with respect to the little-endian byte order of the block itself.  From the perspective of a big-endian machine, these are statements about the high byte of the nonce.
So consider a miner which is big-endian.  The natural algorithm is "start with nonce=0, compute scrypt, increment nonce, repeat", so your "even" nonces will be tried first.  However, when a new transaction (or a new block from another miner) arrives, a new block header has to be constructed, and it would be natural to restart the nonce at zero when this happens.  In order to get a nonce that is "not a multiple of 256", it has to complete 2^24 hashes before being restarted.
Of course, x86 is the most common desktop CPU, and it is little-endian, but most scrypt mining is done on GPUs.  I hypothesize that a majority of these GPUs are big-endian, or at least that some common mining software causes them to increment their nonce in a big-endian manner.  Does anyone know if this is the case?
From this chart, it looks like modern GPUs can run scrypt at roughly 1 Mhash/sec.  So 2^24 hashes would take 16 seconds.  Litecoin is currently averaging roughly 10K transactions per day, which is an average of one every 8 seconds or so.  So it would not be surprising that a miner would  usually not get into their high byte (which for you is the low byte) before restarting.
This hypothesis would also explain why we do not see such a pattern with Bitcoin.  Current SHA-256 ASIC miners run at many Ghash/sec, and so are very likely to go through all 2^32 possible nonces before being restarted by new transaction data.  (We might see patterns in the extraNonce, though.)

Not quietly, only AMD GPU is big endian. The hash still has to be calculated in little endian order. Even hardware can compute the hash without caring endian-ness to obtain a hash value, however, the nonce will be re-check with cgminer scrypt (in CPU) again before send to the pool. If GPU uses big endian to compute the hash and gets a valid result, then cgminer will reject that. So the nonce value must be consistent read by either big or little endian platform. You can use AMD's extension with printf to print the nonce in GPU and the cgminer's nonce to see they are the same value.

The remain 2^8 is zero is also not possible for so many cases. For 2^24 it only needs 16 seconds to compute in 1MH/s GPU, so it will advance to the next byte of 2^8. When any bit of highest 8 bits of big endian is not zero, it could not be multiples of 256 in little endian. Considering the block time of LTC is 2.5 minutes, and Dogecoin is target for 1 minutes, it is long enough for GPU to use the remain 2^8 bits. When it exhaustively searched 2^32 and found nothing, the miner increases the timestamp 1 second and starts over and over again.

You can check the source code of GPU OpenCL scrypt in popular cgminer/sgminer. The OpenCL miner counts the nonce from 0 to an upper value by using thread id as the nonce. So basically it is a incremental value, for example, 4096 threads are issued to compute nonce from 0~4095 (because threads numbered from 0 to 4095), and then 4096~8191 in the second run, and so on. You can add extra printf or applog to cgminer/sgminer to see what the nonce can solve the diff and accepted by the pool. Basically the nonce printed for every accepted diff is also a increment value from small to larger number.

@jclin: Thanks for the comments.  I realized the mistake about the low bit shortly after posting but did not get to correct it until now.  I appreciate the details about cgminer and its interaction with the GPU; I will read them more carefully when I have more time.

I also need to correct my comments. "2^8 bits" is the high byte (or 8 bits and has 2^8 values)

An interesting experiment has occurred to me after reading your answer: conduct the same text on Bitcoin and other SHA-256 coins' blockchain from before the introduction of ASICs, and then again from before everybody jumped into mining with CPUs - the results might have a different distribution, or they might not. Both results would be really interesting!

I agree. The endianness can provide a clue that shows different mining equipments (GPU or ASIC) found the block.

I conducted the following tests using C# (using the block header from the Litecoin wiki; Dogecoin is the same deal). Here's a test using scrypt: (I didn't preset the limit at 14857; it just took so long I stopped it there)
var dict = new Dictionary<uint, int> { { 0, 0 }, { 1, 0 } };
byte[] blockHeader = new byte[] { 0x01, 0x00, 0x00, 0x00, 0xae, 0x17, 0x89, 0x34, 0x85, 0x1b, 0xfa, 0x0e, 0x83, 0xcc, 0xb6, 0xa3, 0xfc, 0x4b, 0xfd, 0xdf, 0xf3, 0x64, 0x1e, 0x10, 0x4b, 0x6c, 0x46, 0x80, 0xc3, 0x15, 0x09, 0x07, 0x4e, 0x69, 0x9b, 0xe2, 0xbd, 0x67, 0x2d, 0x8d, 0x21, 0x99, 0xef, 0x37, 0xa5, 0x96, 0x78, 0xf9, 0x24, 0x43, 0x08, 0x3e, 0x3b, 0x85, 0xed, 0xef, 0x8b, 0x45, 0xc7, 0x17, 0x59, 0x37, 0x1f, 0x82, 0x3b, 0xab, 0x59, 0xa9, 0x71, 0x26, 0x61, 0x4f, 0x44, 0xd5, 0x00, 0x1d, 0x45, 0x92, 0x01, 0x80, };
for (uint nonce = 0; nonce < 14857; nonce++)
{
    var nonceBytes = BitConverter.GetBytes(nonce);
    Array.Copy(nonceBytes, 0, blockHeader, blockHeader.Length - 4, 4);
    var hash = SCrypt.ComputeDerivedKey(blockHeader, blockHeader, 1024, 1, 1, null, 32);
    if (hash[31] == 0)
        dict[nonce % 2] += 1;
}

Results:
0 32
1 29

And with SHA256 (using the block header from the Bitcoin wiki)
var sha = SHA256.Create();
var dict = new Dictionary<uint, int> { { 0, 0 }, { 1, 0 } };
byte[] blockHeader = new byte[] {0x01,0x00,0x00,0x00,
    0x81,0xcd,0x02,0xab,0x7e,0x56,0x9e,0x8b,0xcd,0x93,0x17,0xe2,0xfe,0x99,0xf2,0xde,0x44,0xd4,0x9a,0xb2,0xb8,0x85,0x1b,0xa4,0xa3,0x08,0x00,0x00,0x00,0x00,0x00,0x00,
    0xe3,0x20,0xb6,0xc2,0xff,0xfc,0x8d,0x75,0x04,0x23,0xdb,0x8b,0x1e,0xb9,0x42,0xae,0x71,0x0e,0x95,0x1e,0xd7,0x97,0xf7,0xaf,0xfc,0x88,0x92,0xb0,0xf1,0xfc,0x12,0x2b,
    0xc7,0xf5,0xd7,0x4d,
    0xf2,0xb9,0x44,0x1a,
    0x42,0xa1,0x46,0x95,};
for (uint nonce = 0; nonce < 1000000; nonce++)
{
    var nonceBytes = BitConverter.GetBytes(nonce);
    Array.Copy(nonceBytes, 0, blockHeader, blockHeader.Length - 4, 4);
    var hash = sha.ComputeHash(sha.ComputeHash(blockHeader));
    if (hash[0] == 1)
        dict[nonce % 2] += 1;
}

The results:
0 1908
1 1951

This shows that, regardless of whether the nonce is even, coin algorithms produces roughly the same number of high-difficulty results. (I believe this is a good test of both SHA256 coins like Bitcoin and scrypt coins like Litecoin and Dogecoin; yes, I'm pretending the difficulty is much lower by only paying attention to one byte, but the point remains)
So why are multiples of 256 and even numbers so common in the real world? My guess is that mining software most commonly chooses these nonces, though there's no benefit to it. For example, what you call a nonce divisible by 256 could be considered a number under 2^24 (with reversed endianness). Nonces don't need to be chosen with high entropy, so it's acceptable for them to be somewhat predictable - just as long as you're not wasting your time by using the same nonce twice on the same block header.

Please note that I got the results from scrypt based crypto-currencies. I also did not see the same pattern mentioned in my question found in SHA256 based algorithm. Moreover, running the algorithm only is not accurate, because there is a target value, which can be derived from the difficulty, and the sha256 or scrypt result has to be less than the target. If you are also running scrypt algorithm only, I guess you the same results that odds and evens have no great difference on their occurrences.

I'll see if I can do a proper test with scrypt.

@jclin I've updated my answer to include scrypt. As I expected, even nonces are no better than odd ones. (I'd be highly surprised if they were - it would mean these crypto hashes could actually be easily manipulated) You've found an interesting triviality, nothing significant.

I understand that data (even nonce is the LSB=0) computed with sha256 or scrypt won't produce any significant results of favoring even nonces. When LTC in low difficulty, for example block 0~10, your can see most of then are odd numbers. The nonce found in the block might not be the only solution, but just the first one found to be less than the required target value. So for example, LTC block #5 nonce is 6103, and there should be a even number greater than 6103 can solve the block under the difficulty. Your program just prove that many nonces can match your requirement of hash[0]=1.

So I asked the question because I don't understand that  found in blockchain. I do assume evens and odds should be evenly found in the blockchain because all miners search nonce from 0~2^32. No one will skip odd number because the in pooled minig, if someone skips the odds, he won't get the share which can solve the diff provide by pool. If someone just calculate the nonce on 2^24 space, he might need to alter some data, such as time stamp, to calculate the next nonce from 0 to 2^24. So the last byte with 2^24 forms a 4-byte integer. It does not make sense to ignore 8 bits of the nonce.

See my comment replied below the original question for the endianness issue. Hopefully I did not spend much time on the interesting triviality. I think the most time spent are replying comments, writing small perl script (smaller than comments I replied in words), and crypto currencies and miner software are open source.

@jclin: If scrypt really is secure, skipping nonces or not is irrelevant in either solo or pooled mining.  Every nonce is equally likely to produce a valid block, and likewise, every nonce is equally likely to produce a valid share (which is just a lower difficulty target).  You could run through all numbers in order, or the even numbers, or the primes - it makes no difference.

The endianness might be not an issue because either in big or little endian, it allows a way to increase the possibility to find the nonce quickly compare to others who just sequentially iterate over 2^32 times.
In big endian, the result means > 80% nonces are found under the space from 0 to 2^24, so don't waste time to continue to try 2^24 to 2^32, just advance to next second or alter some data to start finding the nonce from 0 again.
In little endian, the result means > 80% nonces are multiples of 256, so you might also have 80% ~ 90% possibilities to find the nonce that can solve the block.
Because the nonce is not predicable, either counting the nonce from 0 up in big endian or little endian should not be a issue. They always could find a possible solution to the block.

No, I think you have got a misconception.  This approach will not find a winning nonce more quickly - it will be exactly the same.  Every nonce has an equal chance of winning. The value of the winning nonce, if there even is one for a given block, is completely random; it is just as likely to be between 0 and 2^24 as in any other equal sized range.  For some blocks (indeed, the vast majority), there is no 32-bit nonce that wins.  For others there might be many.

So it doesn't matter at all which nonce values you try, or whether you try all nonces for a given block, or whether you give up before trying them all and change the block header in some other way.  At the end of the day, the average number of winning blocks you have found is related only to the number of different valid block headers you have tried to hash - exactly how they differ is totally irrelevant.

And according to my hypothesis, the reason more people are finding nonces between 0 and 2^24 is because more people are looking there - because it happens to be computationally convenient to do so.  If we all switched to a miner that preferred to try nonces between 145235236 and 162012452, we'd expect to find lots of winning nonces in that range, but the total number found would be exactly the same, on average.

I believe every nonce has an equal chance of winning. Considering the searching game is sequential, what nonce you first have or quickly get is the key to get the block solved. Like a dice game, if you know number six shows up frequently, so you could buy six to win more than others. Rolling a dice multiple times and shows 6,6,6,6 does not mean the dice is unfair. It could be followed by 5,5,5,5,4,4,4,4,...,1,1,1,1 and the possibility of every number of the dice is 1/6, and we could be at the 2nd or 3rd appearance of 6.

I'm not sure it is computationally convenient or not to compute only 24 bits of an integer. As I know, except for ASIC miner implementation, the popular cgminer and sgminer scans nonce till 0xFFFFFFFF or time's up or abort due to new block.

Quite right.  What I conjecture is that it usually does abort before getting to 0x00FFFFFF.  Note that a new block is not the only thing that would trigger a restart - so would the arrival of a new transaction that the miner decides to include in the current block (which changes the Merkle root value in the header).  A new transaction arrives every few seconds on average - much more often than a new block, which takes an average of 2.5 minutes.

The "computationally convenient" part is that it's convenient to start with a nonce of 0 after each restart - and this means that low nonces are tried much more than higher ones.  It would not really be any less convenient to start at a nonce of 0xDEADBEEF instead, it would just look weird in the code - but if they did, this question would be about why so many nonces have 0xDE as the low byte.

@NateEldredge Don't forget the timestamp, which should be updated every second (don't know for sure if they actually do that, but this would trigger a nonce restart much faster than a new incoming transaction).

Restarting on every second is a miner choice, not a mandatory requirement for the mining I think. But there should be a tolerant for the stale seconds, not all outdated timestamps are accepted. The new incoming transactions (within few seconds) are not also required to the recent block specially when the fee is zero.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
It is possible to build a P2P system to trade Bitcoins?
It is possible to build a peer-to-peer (similar to BitTorrent) system to trade Bitcoins?
Well, the discussion pointed in the 1st answer is very similar to what I have in mind. But, I have some sub-questions:

Is there any possibility to use blockchains transactions system to have some "cash on demand" to use in trades transactions(maybe with some taxs like fee transactions)? And blockchains can carry more information about what is going on inside this or others sub-systems?
The idea here behind the word "trade" is some system, that allows you to trade your bitcoins for any other currencys or other virtual currencys in any connected market around the world, by simple configuring a new "node" for that market.
ok. More obvius question. How? (1 for me looks like a good idea.)

I think the answer to this question is currently unknown.  There's currently an ongoing discussion about it on the bitcointalk forums.
I'll update this answer if anything comes of it.

well, discussion looks far away from a real solution..

Indeed it does.

My speculative answer here is that it should be possible for currency trading between two crypto currencies to be done safely in a distributed/anonymous fashion. (use new blockchain to track open orders, season with crypto to taste.)
Truly decentralized trading against FX currencies is a lot less plausible.

how the system is supposed to hold/lock bets? I guess this is the final frontier...


text:
Is the NotHaus conviction (Liberty Dollar) relevant as legal precedent?
Bernard von NotHaus (the creator of the Liberty Dollar) was convicted of violating a U.S. federal law that forbids the minting of a currency by anyone in the U.S. besides the federal government.  Might it be claimed that bitcoins are also a currency and their users or creators violate that same law?

Something that shouldn't be left out of any commentary on the topic is the fact that NotHaus specifically advocated for merchants to give liberty dollars as change to unsuspecting customers "at a profit" since they cost less than their face value.  Since no one is trying to pass bitcoins off as U.S. dollars, I think it's pretty safe.

@eMansipater - wow, I never knew that. That indeed sounds a lot like  fraud to me. "at a profit" indeed :)

I probably heard people complaining about how the U.S. government screwed NotHaus unfairly 20 or 30 times before I found this on my own.  It's something Liberty Dollar advocates tend to fail to mention.

There are many complementary currencies in use around the United States quite openly and without government interference, including BerkShares, Ithaca Dollars and similar hyper-local currencies, various bartering or time swapping systems like LETS or Time Dollars, etc. The case you are referring to revolved around minting coins that could easily be confused with US money and allegedly circulating (and encouraging others to do so) to local businesses while passing them off as US money (by a lie of omission, if nothing else).
It may well be that Bitcoin faces legal challenges in various countries, including the US, but this particular case will have set no precedent in that regard.

The convictions, currently under appeal, are for

making coins resembling and similar to United States coins
issuing, passing, selling, and possessing Liberty Dollar coins
issuing and passing Liberty Dollar coins intended for use as current money
conspiracy against the United States

The essenges of bitcoin is a cryptographically signed message and therefore bears no resemblance to United States coins.  The Casascius physical bitcoin and Bitbills are the closest things and nowhere do they come close to a U.S. coin.  The Bitcoin medals / silver 1 ounce rounds at My Bitcoin Mint or MJB Monetary Metals are simply silver commodities no different than the thousands of other silver medals and rounds produced.
There are private currencies in use in certain locales.  Berkshares in Massachusetts and Potomac currency near D.C. even, for instance.  Their issuance has been left unchallenged.
So far, there has been no determination as to what Bitcoin is.  Is it a commodity?  A foreign exchange currency?  A stored value (regulated under the definition of prepaid access?)  But there is little association between Bitcoin and a U.S. coin.

That bitcoins may be "intended for use as current money" would seem to be the resemblance.

von NotHaus has not yet been sentenced, it's unlikely an appeal is actually under way.

The court where NotHaus was tried is a District court (trial court). In the US federal system, trial court decisions are persuasive authority only - this means that other courts can read them and discuss them and use them as guidance, but they are not required to follow them the way they would be an opinion from a Circuit Court of the US Supreme Court.
Also, trial courts make two kinds of determinations - regarding issues of law, and issues of fact.
Issues of fact are going to be specific to that particular case and aren't meaningfully precedent for any other circumstance. An example would be "we find that Col. Mustard killed Miss Scarlet in the kitchen with a lead pipe."
Issues of law could be applied to other cases - e.g., "the Court finds that a lead pipe is a deadly weapon."
So, it's possible that the court in the NotHaus case ruled on issues of law in a fashion that could be extended to other cases - but many of the rulings were likely very fact-specific (and thus inapplicable to other cases), and even rulings on legal issues will function as suggestions to other trial courts.
If NotHaus appeals his conviction, the appeal is more likely to result in binding precedent; but even that would only be binding on other courts within that appellate circuit, for the rest of the US it would just be persuasive (not mandatory).
The bare fact that NotHaus was convicted is not, in itself, any sort of legal precedent, though it may be a clue about the US government's feelings about alternative currencies.

There is no evidence to suggest that law applies to Bitcoin. See also What is the current legal status of Bitcoin?


text:
Where can I find RPC_User and RPC_Password for my Python Script?
I'm still struggling with this to obtain "rpc_user" and "rpc_password" this is the Python Script

I did try others to fill in others network like Blockdaemon.com but it does not work, which is why I take off and leave it empty then I get the same error as per the snapshot below:

I have tried to find LocalHost to support this but it doesn't work even though via CMD and Ubuntu.
Any recommendation? Sorry again to inform I'm no expert in this as I'm a nerd who is still figuring out the way to solve this.  My GOAL is to able to Connect to any LocalHost for me to Post my Bitcoin Transaction.
Appreciate your guidance on this. Many thanks.

Do you have a bitcoin node that are running on your computer?

@vincenzopalazzo - Nope I don't have except for the Bitcoin Core V0.20.0

To use this library you need an instance of Bitcoin core!
If you start with Bitcoin I suggest you to run an instance of bitcoin core and understand how the config it. You can find a good start here!
In addition, to use the lib inside your question you can following the steps below:

Download Bitcoin core and run an instance of it, I suggest you to run Bitcoin core on testnet, because it is not a small instance of "real" bitcoin network
Config Bitcoin core with a conf that accepts the connection on RPC!
With the RPC username and RPC password, use your code to connect to the Bitcoin code RPC interface.

Good hacking!

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Not able to Spend 2-2 MultiSig UTXO
I created 2-2 Multisig Account 2NECouPA4UVNMzX1K7kekc4W3VudDhMdFkM from msrFNhKwLu9GrT3hFoizz21xEwJ61xMsym and n1NPFEJHBA8j63B5dgJ3aQcufA8VmrN27U, I tried spending UTXO from this account but got an error, I was successful in spending UTXO form 2-3 MultiSig Account.
Could someone please help me.
Address_1:
Private Key: 89fcbf126a2d78f4055ff4eb4e44642504d2bea1fea248627ca75eaa35dc56eb
Public Key: 0401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c1
Testnet Address: msrFNhKwLu9GrT3hFoizz21xEwJ61xMsym
Address_2:
Private Key: b74b1862b7e5e92c4fa9ce79826e1579df1b6b09f1f3bf312918f9e6e32f39de
Public Key: 044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b4
Testnet Address: n1NPFEJHBA8j63B5dgJ3aQcufA8VmrN27U
MultiSig 2-2 Testnet Address:  2NECouPA4UVNMzX1K7kekc4W3VudDhMdFkM
Raw_Script:
52410401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c141044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b452ae60f72cc98474313a44b1f4b0c907c2b002ac815a58595a1a28b
Raw_Transaction:
01000000018ba2a19585a515c82a002b7c900c4b1f4ba413434798cc720f36289e812c70c3000000008752410401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c141044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b452aeffffffff01e0083000000000001976a91490b5f4fc981ff94df22a1f845c0b7074623042d588ac0000000001000000

Taking Signature_1 and then Signature_2:
Sig_1: 3044022044ebf0dd5ffe267771987e02a763c3721d4e872931a5b9ec7d05fca0e952dec002205a5315dd4920175ed36d32be7d8011b2d429120bc996408d47e15d4d246982f0
Sig_2: 304402206574c1e54144268079120ab996d84209edf6bde8620108aab5b1e8ba0a0e7b5b022006b02e6d31459f732d16bf39ea488485c3a7c2d1106c4a9210916df1a9900b73
Transaction_to_Broadcast:
01000000018ba2a19585a515c82a002b7c900c4b1f4ba413434798cc720f36289e812c70c300000000fd190100473044022044ebf0dd5ffe267771987e02a763c3721d4e872931a5b9ec7d05fca0e952dec002205a5315dd4920175ed36d32be7d8011b2d429120bc996408d47e15d4d246982f00147304402206574c1e54144268079120ab996d84209edf6bde8620108aab5b1e8ba0a0e7b5b022006b02e6d31459f732d16bf39ea488485c3a7c2d1106c4a9210916df1a9900b73018752410401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c141044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b452aeffffffff01e0083000000000001976a91490b5f4fc981ff94df22a1f845c0b7074623042d588ac00000000

What error did you get?

https://tbtc.bitaps.com/broadcast: mandatory-script-verify-flag-failed (Operation not valid with the current stack size) (code 16)
https://live.blockcypher.com/btc-testnet/pushtx/: Error validating transaction: Rejected script for input 0 referencing c3702c819e28360f72cc98474313a44b1f4b0c907c2b002ac815a58595a1a28b at 0

What is the value of bitcoin you want to unlock with the transaction described inside the post?

UTXO value is 0.03148581 and in this transaction, I want to unlock 0.03148. Earlier I have tried 2-3 MultiSig Transaction and faced no problem. I have always encountered a problem when trying to spend from 2-2 MultiSig Address.

@YashMadhwal can you add the code of the scriptSig, please?

@vincenzopalazzo I am manually making the transaction from self-created python Programs. I was able to verify 1-1 P2SH, 2-3 P2SH Transaction. I am getting same error for 1-2 P2SH Script.

1.Sign the Raw_Transaction above with private key1.
The output would be
01000000018ba2a19585a515c82a002b7c900c4b1f4ba413434798cc720f36289e812c70c300000000d200473044022028302ac2842f56c7b77c93e508fdd2ddaae73891a59ffcd00a225761e2f4097c02200b5002b74c2ba90bb70774d0bd449a13ff4d94d267004ad4d04d9e0672d6f33d014c8752410401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c141044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b452aeffffffff01e0083000000000001976a91490b5f4fc981ff94df22a1f845c0b7074623042d588ac00000000

2.Sign the partially signed transaction above with priavate key2.
The output would be
01000000018ba2a19585a515c82a002b7c900c4b1f4ba413434798cc720f36289e812c70c300000000fd1a0100473044022028302ac2842f56c7b77c93e508fdd2ddaae73891a59ffcd00a225761e2f4097c02200b5002b74c2ba90bb70774d0bd449a13ff4d94d267004ad4d04d9e0672d6f33d0147304402203262e78af66954397c190cdcd69e2cdbc8957d4280caf61e8be15012c4a981d102207d4fc48692d30bdb054f739c8138c2c10901c4edf44bf7f2ff607d5134973ae9014c8752410401e52f885e02000e7ec5f410f2e680cfd0ca8be75d5425c75934499fc17e24152e1f9a391764b858ac276877b56253a7a1beafe8f7574f572461c3780a3778c141044bd79509fea54fc8118eed193a295a34b8dcbd030a09c7fcf815c785846dca56b3d6ddfd96e582a96e6e13e90569dbf8ee52c2517bfbed22f8ad17d850d283b452aeffffffff01e0083000000000001976a91490b5f4fc981ff94df22a1f845c0b7074623042d588ac00000000

3.Now you can broadcast the transaction signed with two keys

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does sipa's bitcoin-seeder determine which IPs to return out of all the ones it knows to be available for P2P connection?
I believe there must be a heuristic that determines which IPs are returned to clients by the seeder.
The seeder may have a list of hundreds of available nodes, but it only returns a reduced subset when queried.
Where in the code is the determination made of which IPs to return in response to a DNS query (out of all nodes the seeder is tracking and marks available)?
Note: The author of bitcoin-seeder (sipa) has stated that as many IP's as fit in a UDP data packet are returned  (So there is no max_addr_return variable or such similar setting)

The answer is simple: it returns as many as fit in a DNS UDP packet (512 bytes).

Thank you Peter, that is informative; maar .. can you shed some light on how the addresses are chosen when the packet is filled ?  For example, btc.intersim.com shows 3681/948038 available;  when queried for IPv4 it returns 24 addresses and when queried for IPv6, only 14. (This makes sense, as less IPv6's will fit in a 512 byte UDP packet).  But how does dnsseed pick these out from the over 3,600 that it judges "available" ?  (in this example)

Note: I have edited the question;  I originally asked how many IP's are returned; but of greater interest IMO is how these are chosen from the set of nodes that dnseed has marked as available. Is it random or is there some priority function ?


text:
Lose wallet access
how to detect the name of the wallet used with the address based on the address.I lost the smartphone.there the transfer of coin to my wallet address but I can not access the wallet caused by the absence of recovery phrase .. How to make the coin can be moved to my new address..merge already got to my old wallet

So to be clear: you lost the phone and do not have any backup of the phone, or any backup of the wallet that was on the phone?

Something off-topic: Dogecoin is a deprecated coin, should attempt to sold/use as much as possible afterward since there may be security risk related.

Unfortunately without your backup phrase there is no way of getting access to your wallet. Your wallet is gone unless you find your phone.
See the point of a wallet (and the private key of the wallet) is to keep your coins yours. So unless you own the private key, you don't own your coins.
If you have your private key displayed and written down somewhere you can access your coins. If not forget it, there is no way to recover a lost wallet, without backup phrase.

The point of phrase is to generate private key using words given by you. So inorder to own those lost coin you need that phrase .OR if you have ever noted your private key then you can still get back your coin else there is no such way.


text:
How to reduce disk-space requirements of Bitcoin Core wallet?
I want to install Bitcoin Core wallet on my computer, but his blockchain is too big (more 230 Gb).
How to reduce Bitcoin Core wallet?

You can use a prune option to specify the amount of disk space you would like Bitcoin Core to use. This option allows you to keep only the latest block information instead of storing all the data.

find your configuration file bitcoin.conf (here you can find the list of possible locations depending on your operating system);
set prune parameter to the desired target size in MiB (for example, prune=2048);
restart the wallet.


text:
pycrypto or libssl not found, decryption may be slow
My wallet.dat file is corrupted and everytime i try to run Wallet QT client will shut down as unexpected error and i have no longer access at my wallet on this way.
I have tried to dump private keys through pywallet but everytime i execute commands it shows pywallet or libssl not found...

Actually i don't have much experience with this, Downloaded openssl and pycrypto then extracted both files to C:\Python27 , im doing this wrong if yes please help me to setup.

SC: https://prnt.sc/rufmpy

Your image shows two messages:
There is a message

ERROR:root:Couldn't open wallet.dat/main

It suggests you should close Bitcoin if it is already running. I would use Windows' task-manager to see if bitcoin-qt, bitcoind etc are running (Ctrl+Alt+Del in Windows-10 should bring up a menu from which you can select task-manager). You can close those processes from task manager if necessary.
Since your screenshot shows a second attempt without this error, it looks like you shut down Botcoin-qt OK and the command completed OK.

and

WARNING:root:pycrypto or libssl not found, decryption may be slow

This is just a warning, it doesn't mean that the command won't work, just that it may take longer than normal.
The message suggests pywallet will use slow internal cryptographic functions if it doesn't have access to a fast external library of cryptographic functions.

So your wallet.txt file should show you the information you wanted to extract.


text:
Is it possible to handle BCH transactions on Bitcoin Core wallet?
I've installed Bitcoin Core on a server and it works well for BTC. I would like to know can I use the same server and platform to support BCH too?
I know that the addresses generated in Bitcoin Core are usable for BCH too. But how if I am able to handle BCH transactions in this machine, how can I differ them from BTC ones?
Thank you in advance for your replies.

If your BTC addresses aren't SegWit addresses, you can use dumpprivkey to extract your private keys and use them in a BCH wallet. You can import them to Electron Cash, which is a wallet software, or Bitcoin Unlimited/Bitcoin ABC, which are equivalents of Bitcoin Core. I'd advise against using BU/ABC and Core on the same machine, because both of them use the incoming port 8333. Besides, you might need to set datadir option otherwise they'd corrupt Core's blockchain and wallet databases.

do both Bitcoin and Bitcoin Cash use the same blockchain too? If so, and if I install both on a same server, how can I differentiate the incoming BTCs from BCHs?

They have separate blockchains since BCH was born. You need to use different software to receive BCH and BTC, which would tell you which currency you receive.

Thank you so much. Just something is strange for me. Binance and some other exchanges which I have checked, provide the same address for both BTC and BCH receives. How is it possible? I've got a bit confused.

There are lots of coins that use the same crypto to sign transactions (ECDSA on curve secp256k1). BTC and BCH included. So you can use the same private key and public keys on both chains (a public key is a private key times the generator point; an address is a hashed public key). Usually different currencies use different address formats. This is to prevent the case that your BCH wallet generates an address that is compatible with both currencies; someone could send BTC to it and those coins could be lost as a result. BCH also has a second address format, but it didn't exist when BCH was

Created, so you can import the private key from a BTC wallet to BCH wallet or vice versa and use one address for both currencies if you want. If you have a wallet that only lets you receive BCH, I'd suggest that you cashaddr.bitcoincash.org to generate a BCH-only address to avoid someone sending BTC to you by mistake. Are there any other points that I've forgotten to address? @MohammadSaberi

You gave me lots of information. Thank you so much @MCCCS


text:
Can PUSHDATA/OP_RETURN be used to break a trail of transactions permanently?
I was reading the Bitcoin wiki on how the Bitcoin protocol has no "From" address and the closest thing to a from address is a "previously receiving address".
The article then proceeds to show a transaction that breaks Bitcoin chain explorers: 54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f
This is indeed true. Web-based explorers such as blockchain.com and BlockCypher cannot resolve the Input address.
I see in the transaction's details that the tx creator has placed a PUSHDATA(72)[somedata] operation at the Input.
Can this effectively be used to break/hide a Bitcoin transaction chain? If yes, what is the point for alternative Privacy-oriented coins such as Monero, when absolute privacy in transactions (hidden-input transactions) can be created in Bitcoin?
I'm probably misunderstanding something, and If you can point me in the right direction, I'd be more than grateful.

Can this effectively be used to break/hide a Bitcoin transaction chain?

No, the block explorers you've mentioned simply do not include code that is capable of decyphering the nonstandard transaction you've linked to.
Importantly: Bitcoin transactions do not include a 'from address', instead they reference a valid unspent transaction output (UTXO) that they are spending. That said, the majority of transactions throughout history can be decoded to present the user with a 'from address', so this is simply a user-friendly abstraction that block explorers make. The 'from address' is not inherent to the Bitcoin protocol.
So in a simplified sense, rather than trace the transaction history via "this address, and then this address, etc", you would say "this UTXO, and then this UTXO, etc".
Thus, using bitcoin-cli you can easily trace the transaction history. Here is the output when using the getrawtransaction RPC for the transaction you mentioned, with verbosity=1:
user$ bitcoin-cli getrawtransaction 54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f 1
{
 "txid": "54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f",
  "hash": "54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f",
  "version": 1,
  "size": 159,
  "vsize": 159,
  "weight": 636,
  "locktime": 0,
  "vin": [
    {
      "txid":
"a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c",
      "vout": 0,
      "scriptSig": {
        "asm":"3045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e[ALL] -1",
        "hex":"483045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e014f"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.09000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a86e8ee2a05a44613904e18132e49b2448adc4e6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB"
        ]
      }
    }
  ],
  "hex":"01000000010c0e314bd7bb14721b3cfd8e487cd6866173354f87ca2cf4d13c8d3feb4301a6000000004a483045022100d92e4b61452d91a473a43cde4b469a472467c0ba0cbd5ebba0834e4f4762810402204802b76b7783db57ac1f61d2992799810e173e91055938750815b6d8a675902e014fffffffff0140548900000000001976a914a86e8ee2a05a44613904e18132e49b2448adc4e688ac00000000",
  "blockhash":
"000000000000000c15dfb68cc1abead192f718cf8b772977d79938f3a4259afa",
  "confirmations": 299789,
  "time": 1378742541,
  "blocktime": 1378742541
}

So we can see that the input is the first output created by the transaction with id:a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c. Using the same method as above, we can look up that transaction:
user$ bitcoin-cli getrawtransaction a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c 1
{
  "txid": "a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c",
  "hash": "a60143eb3f8d3cd1f42cca874f35736186d67c488efd3c1b7214bbd74b310e0c",
  "version": 1,
  "size": 212,
  "vsize": 212,
  "weight": 848,
  "locktime": 0,
  "vin": [
    {
      "txid":
"c079314b17b7a2c3fbe879e6fc610291c685f6f7819d70bef785295c774b1e04",
      "vout": 1,
      "scriptSig": {
        "asm":"3045022100d4f73a357e323a3f0666264bd018f25296682bd7db12979890b3952b159337d7022039ebfd0d3deeb6236545e6d05d65e9fa395544f69e5275fab2e4f73cc7c20286[ALL] 0223a6fbf80fe06efa9a8707620a1215cf6a5834e6f81ca6592b0e7195fe92eae7",
        "hex":"483045022100d4f73a357e323a3f0666264bd018f25296682bd7db12979890b3952b159337d7022039ebfd0d3deeb6236545e6d05d65e9fa395544f69e5275fab2e4f73cc7c2028601210223a6fbf80fe06efa9a8707620a1215cf6a5834e6f81ca6592b0e7195fe92eae7"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.09000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP 0 OP_LESSTHAN OP_VERIFY OP_ABS 1 16 OP_WITHIN OP_TOALTSTACK 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 OP_CHECKSIGVERIFY OP_FROMALTSTACK",
        "hex":"76009f69905160a56b210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71ad6c",
        "type": "nonstandard"
      }
    }
  ],
  "hex":"0100000001041e4b775c2985f7be709d81f7f685c6910261fce679e8fbc3a2b7174b3179c0010000006b483045022100d4f73a357e323a3f0666264bd018f25296682bd7db12979890b3952b159337d7022039ebfd0d3deeb6236545e6d05d65e9fa395544f69e5275fab2e4f73cc7c2028601210223a6fbf80fe06efa9a8707620a1215cf6a5834e6f81ca6592b0e7195fe92eae7ffffffff0140548900000000002d76009f69905160a56b210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71ad6c00000000",
  "blockhash":
"0000000000000026c3b45ad70e4622dcdaffc8cad2b202d1d5a4254625166ec9",
  "confirmations": 306793,
  "time": 1375519263,
  "blocktime": 1375519263
}

And we could continue following the transaction history in this way, so you can see that this type of nonstandard transaction does not break the transaction history. Keep in mind that a bitcoin is fungible, so while we can trace a general transaction history, we cannot trace an 'exact coin' through time, as such a thing does not exist. This allows for privacy and fungibility enhancing techniques such as 'CoinJoins' to function.

Thank you for your well-written answer. One more comment on it, out of curiosity: What was the input UTXO for the first transaction on the genesis block?

@DimitrisSfounis that question has an interesting answer! The first tx in each block is a special type of tx with no inputs, called the coinbase transaction. The output it creates is composed of the miner's block reward + tx fees from that block. However, the genesis block is hardcoded into the client, so the UTXO set starts being populated from the second block onwards. Because of this, there is no valid UTXO for the genesis block coinbase tx, meaning those coins are unspendable. See: https://bitcoin.stackexchange.com/questions/10009/why-can-t-the-genesis-block-coinbase-be-spent


text:
How much should I spend when I send BitCoin to other people using electrum wallet?
The fee displays "Target: Within 10 blocks, Current rate: 2.5 sat/byte" when I use electrum wallet to send BitCoin to other people.
I can't understand completely the means of "Target: Within 10 blocks, Current rate: 2.5 sat/byte" ?
How much should I spend if I send one BitCoin to other people ? Thanks!
I hope you give me the details about how to calculate the fee!
Added Content
To Abdussamad: Thanks!
1: The sat is 0.00000001 BTC , right?
2: I send one BTC to other people, how can I know the byte?
   If I know the byte, I can calculate the fee= byte * 2.5* 0.00000001 BTC

Thanks! but I still confuse it, Could you tell me how much I should pay  if I send  one BitCoin to other people?

tx fees are calculated based on the size of a transaction in vbytes, not by the amount of btc being sent. A transaction with lots of inputs or outputs will cost more than one with only a couple inputs/outputs. Further, transaction fees follow a dynamic market equilibrium, as miners will include the txs which pay them the most at the time (usually calculated in satoshis/vbyte). So there is no generic answer for ‘how much to send one bitcoin’.

Does this make sense to you?
---------|-------------------
low/slow........high/fast
The further left you move the slider the lower the fee you pay and the longer it'll take to confirm. The further to the right you move the slider the higher the fee and the faster it'll confirm. If you still don't get it go to tools > preferences > fees tab and check edit fees manually. Now on the send tab you'll be able to see the whole calculation including the absolute amount of fees you will pay for a particular transaction.

Thanks! Would you please to see my added content in the question?

@HelloCW You forgot this part: "go to tools > preferences > fees tab and check edit fees manually. Now on the send tab you'll be able to see the whole calculation including the absolute amount of fees you will pay for a particular transaction."

Thanks! I find the byte is 224 for sending 0.5BTC, and current 1BTC=6400USDT, so the fee will be 2240.000000016400=0.014 USDT, it's so cheap, is my calculation right?

224*fee rate = fee in satoshi. if the fee rate you set using the slider is 1 satoshi per byte then it's 224 satoshis which at 6400 is $0.014 yes. transaction fees have gone down a lot since the 2017 peak.


text:
Signature generation
I am trying to unwrap bitcoin transaction generation process.
A bit confused about signing part.
My understanding is the transaction is sha256'd, then sha256'd one more time, then ECDSA'd.
Based off https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm, ECDSA will first hash the message. Does that mean the transaction is sha256'd 3 times in total?
All the best!
Johnny

No, only two hashes. The hash itself isn't typically described as a part of ECDSA though the input must already be hashed (because e.g. a signature of 0 is trivially forged).


text:
Public Addresses: '3' vs '1' in front [Bitcoin]
I just wanted to confirm, is it true that for a bitcoin (public) address it should always have a '1' in front of it. For certain transactions though I see that there is a '3' in front. How is this possible, and why is it a '3'?

A Bitcoin address prefix is a function of the locking script type for a particular transaction output.
Older Bitcoin Pay-to-Public Key Hash (P2PKH) scripts are associated with addresses that start with the number 1, resulting from a one byte version prefix prior to base58check-encoding being set to 0x00.
Newer Pay-to-Script Hash (P2SH) transactions start with the number 3, resulting from a one byte version prefix prior to base58check-encoding being set to 0x05.
Examples of P2SH are singe single P2SH signature addresses, multisig addresses, and nested P2SH(P2WPKH) that resulted from segwit to maintain backward compatibility with older wallets that are not explicitly segwit-enabled to wallets that are segwit-enabed. Such addresses conform to the BIP 49 hierarchical deterministic scheme.

BIP32 is the one that outlines the HD key derivation.

BIPs 44 and 49 define conventions/schemes for how to specifically apply BIP 32 HD technology. Both BIPs 44 and 49 reference BIP32.

Addresses starting with the number “1” use the P2PKH (pay to public key hash) whereas an address that starts with the number “3” uses P2SH (pay to script hash).
In the first the script only check if the signature is valid by comparing a hash of your public key (the address starting w/ 1) and the digital signature, both created by your private key.
For the P2SH (used by multisig transaction) its slightly more complex where different scripts need to produce the same results when executed with the right cryptographic parameters.
more here
What is P2PK, P2PKH, P2SH, P2WPKH - ELI5


text:
How are transaction fees collected in Bitcoin?
I'm looking into the structure of blocks in the Bitcoin blockchain, and I can't figure out when\how the fees collected by miner of the blocks are transferred to the miner.
According to what I can tell they are not a part of the coinbase transaction (which as I understand has to be constant since changing it after discovering a block would change the hash of the block).
Are the fees paid as separate a transaction? Are they written directly to the UTXO without appearing on the blockchain? Something else?
Thanks!

The coinbase transaction itself has the subsidy/coins for mine a block + all fees of the transactions of that block.

Thanks! If this is the case, how is this implemented in a way which does not change the hash of the block once it's filled out?

@MayaD The entire contents of the (candidate) block, including the subsidy payout, is determined before mining even begins. Nothing can be modified about a block afterwards, as it would invalidate the proof of work. When a miner wants to update the contents of the block they're working on, mining continues by working on a new, updated, block candidate.

Thanks again! If this is the case, is there a way of determining which part of the fee paid to user x came from user y? Do you maybe have a reference to the relevant place in the source code?


text:
Secure way to store BTC over a long time - and its risks?
What are the most secure way to store a huge amount of BTC over a long time and its (detailed) risks? A other assumption is that the owner does not have a very technical background, thus it will not be possible to verify the code of a wallet generator.
I am looking for a detailed overview of the risks. Even unlikely thinks like a biased random number generator of java script used by: https://www.bitaddress.org/
Or that the site is hacked and wallet generation script is malicious just when I want to use it.
An other example would be, when I use MultiBit and I store the seed in safe-deposit box it might happen that the software is not longer available and it might be difficult to recover the keys from the seed.

Related question: How to save bitcoins as paper

Bitcoin Armoury is the best thing out there for this.

What you want to do is create a new wallet with armoury, create a receiving address and send your BTC there.
The best thing is you do not need to even be connected to the network, synchronized or anything. Armoury can run offline in the dungeons far underneath the earth (like your cellar :) )
You then create a paper backup and print it out 2 or three times. Go and store it in your bank, in your important documents and at your mums house.
Delete armoury. (Yes, but make sure you have your paper backups stored safely!)

Your coins will hang in limbo (on the network) without any transaction history or block chain tracking. COmpletely anonymous and unclaimed.
Now- You might feel like you just threw your coins into thin air and have this uneasy feeling of you will never get your coins back! I know I did. So this is what I did.
I followed the whole process I mentioned above. Created a test wallet. Went to another computer somewhere else and did the same, except I imported the wallet from the paper backup. SYnchronised to the bitcoin network. Viola - The coins appeared in the transaction blocks and in my wallet ready to spend

It is also good for managing many online wallets at the same time. One for savings, possibly donations from your websites or blogs, and a personal one, and even offline unsynchronized for the long term anonymous storing of coins.

As long as the bitcoin network will be running you will never lose offline transactions. Just make sure to keep your paper backup in atleast 3 secure seperate place- and no. Do not store it on picasa albums or gdrive.. keep it offline in a bank, locker and at your nans house under the bed, laminate it, put it in a box and bury it in your back yard next to the tree house.

The best way is to generate wallet off-line.
The secure of your storage is the same as secure of your off-line machine. You may aware off TEMPEST only, of course if only nobody can get access to your off-line machine.
You can use for this Vanitygen.
You can download vanitygen here.
Send your bitcoins to address that you generate on off-line machine, and keep private key of this address safe.

The best way to securely store bitcoin is by using what's commonly called "Cold Storage". You do this by generating and address/private-key pair, sending bitcoin to the address, and keeping the private key in a safe place until you're ready to spend it.
There are a number of ways to do this, but the easiest I've found is to create a wallet with BlockChain.info. On the "Receive Money" tab, there is a "More Options" button that will allow you to create a Cold Storage address. The key pair is generated on your local machine, so you shouldn't have to worry about the private key getting out. In the future, you can use this private key to spend your funds using any client, including BlockChain.info.
Since we're trying to do this securely, keep in mind that nothing is absolutely secure. And that if someone has access to your computer during this process, either because you gave them access or because they hacked into it, they can still obtain your private key and spend your funds.

I would say that a paper wallet stored in a bank vault with no other copies made would be the safest. The only risk is that the bank gets robed or the paper deteriorates (which could be solved by using a higher grade material.)
Though this is probably overkill. If your looking for a practical very secure solution I would recommend using Armory's cold storage system.


text:
Why did Bitcoin transaction volume heavily increase in November and December of 2011?
Looking at this chart:
http://blockchain.info/charts/estimated-transaction-volume
It's clear that the amount of bitcoins moved between November 14th and December 12th of 2011 was much larger than any previous month, even compared to the big boom in September.
The number of transactions is about the same as previous months. This implies a few big transactions or generally large transactions. What is the reason for this?

I`ve noticed an incrased activity in my calculator website as well, so it might be a general increase in people's interest in Bitcoin. These might be worth taking a look - http://www.google.com/trends?q=bitcoin&ctab=0&geo=all&date=mtd&sort=0 , http://www.google.com/insights/search/?hl=en-GB#q=bitcoin&date=1%2F2011%2012m&cmpt=q

It dropped again in january...

I'm not sure the volume actually did increase so much in November and December.
The actual amounts transacted each month were:
Jan 31 2011   3,679,198.19243835
Feb 28 2011   4,533,818.22264172
Mar 31 2011   9,331,953.39257620
Apr 30 2011  13,893,407.03577082
May 31 2011  11,850,890.09316489
Jun 30 2011  73,031,161.99932121 <-- biggest
Jul 31 2011  37,718,094.01889341
Aug 31 2011  17,348,635.19178118
Sep 30 2011  17,616,839.59721035
Oct 31 2011  12,008,040.32522139
Nov 30 2011  49,968,992.05725216
Dec 31 2011  46,978,824.26111485
Jan 31 2012  11,664,075.33329784

The blockchain.info graph appears to ignore coins which are moved more than once in the same block.
To see that the blockchain.info graph is ignoring some volume, consider block 133233.  That's just one of the >100 blocks from 25th June, and it alone contains transactions worth 2,420,580 BTC.  However, the blockchain.info graph shows that no single day in June had a volume over 1 million BTC.  Scrolling to the end of block 133233 shows a whole page of small payments from a 46k BTC address, which the blockchain.info graph ignores.
According to the blockchain.info graph, the biggest day in December involved transactions worth 5.834 million BTC.  There was only one day in December with that much volume, and that was December 6th, with 6.903 million BTC.  On December 6th, the volume was dominated by a 440k coin being moved 15 times, accounting for 6.601 million of the day's 6.903 million volume, so the blockchain.info graph must be taking 13 of these 15 movements into consideration.  The 15 movements occurred in 13 blocks - the coins move twice in each of blocks 156242 and 156346.
The origin of this huge coin was on November 16th, ten 50k coins were combined into a single 500k coin.  The coin moved around a lot from address to address until 8th December 2011, when it was broken up into hundreds of small pieces.
Edit: see this graph of "bitcoin days destroyed", which ignores rapid repeat coin movements by weighting transactions by the amount of time since the inputs were created.  It mirrors the data I pasted above, showing that June was a bigger month than November.

Could it be Christmas shopping? People who have thick bitcoin wallets, needing dollars to buy Christmas presents? Many online retailers make half their money by selling Christmas presents.

Let's say I have just one address in my wallet with 1,000 BTC on it.  I then send to you five separate transactions, each in the amount of 1 BTC.  The blockchain will then show 4,990 BTC of transfers yet only 5 BTC was truly transferred.
Additionally, if I were to begin using the encryption feature in the latest Bitcoin.org client, my coins will get moved to new addresses -- thus possibly contributing to the volume spike you saw.

Has it not always been the case that the "change" part of a transaction is indistinguishable from the "sent" part? The question is what's different about December.

@jl6 indeed this has always been the case. Even if it weren't and 0.5 did introduce it as a new feature, we'd expect to see a sustained burst of volume, whereas the chart shows about a two-day spike and a return to normal volumes. I'm sure there's one gigantic transaction to blame, if someone with WAY more time than me wants to check BlockExplorer.

@DavidPerry Mt.Gox did a bunch of big transactions like this at the time. (You can follow it back to the 424242 BTC transaction they did to prove they were still in control of the funds after the hack last summer).

@jarpiain you should write that into an answer since it would appear to explain this phenomena and I'd like to see you get credit for your answer.

I think the maths is wrong in your answer.  Also I think you mean "if I had just one transaction output in my wallet", since it's possible to have multiple separately spendable outputs at the same address.  And then the first would move 1000, the 2nd 999, etc. 1000+999+...+996 = 4990.

Heh, you are correct, 4990.  Edited.

One reason could be that Mt.Gox cut their commissions in half from Dec 25th to Dec 31st.

Nope, Transactions are between November 14th and December 12th


text:
running a full node on a network restricted to outbound connections on port 80 via proxy
Wanted to know if there is any way i can run a full node on a machine in a restricted LAN that can not exit outbound packets except to a specific proxy on port 80 ?
(an answer requiring to use an additional special server to forward packets that sits on an open network can be considered too) can SOCKS help ?


text:
How much can I earn with AntMiner S7 miner
I have started to learn about blockchain technologies, BTC and other crypto-currencies and right now interested in mining.
I know that mining of BTC is not very profitable right now, but other currencies can be profitable.
I looked at ETH, DASH and Monero and according to this site I can earn near 150K per day with AntMiner S7, which seems to be unrealistic.
Please help me understand how this stuff works, is it real or have I some misunderstood something?

You can't use AntMiner S7 miner for Monero. Only for Bitcoin.
ASIC miners like AntMiner are configured to calculate specific algorithms only (in this case AntMiner calculates SHA256 hashes). Monero uses a different one.
There are currently no Monero algorithms (CrytoNight) ASIC solutions, that is the reason the hash rate of the network is low.

For more info see https://www.reddit.com/r/Monero/comments/4x58kh/hashrate_question/

Well, BTC limitation is not a true. But yes, sha256 world is not quite big.
Mining btc on antpool will give you basic statistic, it's depends on your local costs and power limits more than the your Antminer can do)
Ok, I have custom build S5 with 4 hash boards that can provide ~2Th on freq@275(this is my own limitations).
Okay back to PnL, so I'm able to mine ~0.001/day BTC on antpool.
Then I moved to multipool and started mining alt coins that provided much more profits for me, depends on coin ~ ~0.002-0.004/day BTC
https://www.multipool.us/dashboard/pools/sha256
You may try to find another alt coin pools, but keep in mind your antminer works with SHA-256 algorithm only.
Hope it helps.

BTC mining profitability depends on KWh price and bitcoin price. Use this calculator.
https://www.coinwarz.com/calculators/bitcoin-mining-calculator.
Remember Antminer S7 only support SHA-256 mining algorithms.  You need to find a pool that support other SHA-256 cryptographic currencies.


text:
Using btc-e in the United States and depositing/withdrawing USD into btc-e?
I am located in the United States, and was wondering about the complications of using btc-e to make trades in the USA, such as the complications in depositing and withdrawing money in the form of USD.
When I try to deposit USD into btc-e, almost all the options there to deposit money are not supported for US residents such as Perfect Money, OKpay, EgoPay. The other options are Interkassa and Payeer but these sites are in Russian and hard to navigate. There is one more option of wire transfer, but this requires a $2000 minimum. Does anyone have any advice in relation to depositing USD?
Even if we get over the hurdle of depositing USD funds by bypassing it and buying a bitcoin from coinbase and transfering it over to btc-e, and then buying other currencies such as ltc and nmc, eventually when I sell these for USD on btc-e, am I going to have trouble taking the USD out of btc-e? I ask this because it was so hard putting USD in, that I am wondering if it is the same way taking it out?
If anyone in the USA has been using btc-e lately, please advise me on the difficulty or liklihood of depositing USD but more importantly withdrawing USD from btc-e, and how? Thank you.
I guess a second question would be if BTC-e is hard to use in the USA, is there any other exchange in the USA for trading alternative currencies such as LTC, NMC, etc...?

Note, Wire transfers are not available for US Citizens/US Banks right now, "We don't accept international wire transfers from US Citizens or from US Banks
All transfers from US Citizens or US Bank will be refused by bank"

This question is about deposits, not withdrawals.  Please edit the tags.

If you're willing to buy BTC on Coinbase to xfer to BTC-e, when you want to cash out wouldn't you just trade over to BTC on BTC-e to xfer to Coinbase to sell for USD then withdrawal?

I had the same trouble adding funds to btc-e. Best way to do it is using a wiretransfer. They give you the information you need for your bank to send funds to your account on btc-e.
However the way I added funds is this creat an account with www.virwox.com . You can add USD from your credit card onto your account on the website. From then you have to trade in USD for linden dollers. From there you can transfer the linden dollers into bitcoins. Then send the bitcoins to your btc-e account and there you have it! The most complicated way to get funds onto btc-e.
Depending on how long you have been a member on virwox is dependent how much you can transfer from your credit card.
The reason other sites don't allow adding through use of debit or credit cards for cryptocurrency is because they have a non refund system where credit cards and debit cards have a refund system in place directly contradicting the websites terms and agreements.

I wonder if banks in the cayman islands would accept btc-e as deposits in us dollars in a savings account you opened in their bank.  If they did, then you could remotely transfer from your account in the caymen islands to your bank account in the US.  You can remotely open an account in the caymen islands without going there.  Its worth a try...I will have to figure out the answer to that same question soon.


text:
Can I emulate a graphics card using software, and use it for mining?
My name is Ben and I'm working with a server technician called Fab.
We are using Team-viewer to work together on this question to make it as concise and to the point as possible.

We have set up a Ubuntu 13.10 VPS server

Next we downloaded http://www.forked.net/~apex/cgmon/cgmon.tcl (a .Tcl script found on this forum page: https://bitcointalk.org/index.php?topic=353436.0

(Fab:)We managed to install X Server and Lite KDE Desktop environment, and we can successfully connect via VNC to the VPS desktop.

(Fab:) So now: what we would like to understand is whether the host machine where the VPS container is sitting must have a graphics card or if mining using a VPS server could be achieved even without the host server having a physical card, perhaps in a different/emulated way?
The Theory
Now we also want to hook this all up to Cairo grahics lib http://cairographics.org/ (this is a pure c++ graphic processing library for pre-generating images on the server side so there should be no need for a graphics card).
My personal line of thought (Ben's) is that a hash has binary data.
UFUYFYF*^R&^R*IYG*R*FUYFUYFUDKYTDLUFU...

but much longer...
now go and get any image from your desktop and open it with a text editor and you will see some thing like this:
ÿØÿà JFIF  H H  ÿÛ C ...

The difference is not much (in my opinion) because graphics cards are made to process images such as .jpg / .png/ .gif/ .bmp, etc. They do this very fast because the start of the file or maybe even the extension is telling the graphics card how to decrypt; where as a hash is the same, only the description method is a secret that must be tried with many variations of description (hence the term hashing refers to multiple attempts).
Now If you read the wiki link above it explains that Tcl was originally "born out of frustration" and If you scroll down the Wiki to Features one listed is: Extensibility, via C, C++, Java, and Tcl.
So, seen as libcairo is pure c++ and Tcl can run C++ commands, what I would like to know is how can we link the two...

Chances are there is no GPU in the physical host server, servers don't need them.
You could CPU mine, but it would be pointless for Bitcoin, Litecoin and most of the Alt-coins because you just wouldn't have enough processing power to generate anything but dust.
Sorry it's not a helpful answer, but it's better than no answer!


text:
Why does the threshold apply to the MUST_SIGNAL phase in revised BIP 8 (lot=true)? Why doesn't it enforce 100 percent signaling?
BIP 8 states that:

During the MUST_SIGNAL phase, if (2016 - threshold) blocks in the
retarget period have already failed to signal, any further blocks that
fail to signal are invalid.

Why doesn't it enforce 100 percent signaling during the MUST_SIGNAL phase rather than merely the threshold?

nickler answered this on IRC.

In a mixed network, the rules can become active, but in two separate chains because lot=true nodes will reject blocks from the lot=false chain which doesn't require 100% signaling.

The MUST_SIGNAL phase (when lot=true) overlaps with the last two weeks (2016 blocks) of the STARTED phase (when lot=false). In the case that the threshold of miners signaling is met (but not 100 percent of miners signaling) during these two weeks you don't want to create a chain split between lot=true and lot=false nodes for no reason. If MUST_SIGNAL enforced 100 percent signaling and there wasn't 100 percent signaling during this period you would get a chain split between lot=true and lot=false nodes.


text:
What is the control block in Taproot?
What is the definition of "control block" in the context of Taproot?
It is referred to in standard.cpp in the Bitcoin Core repo and in BIP 341.

There are two possible ways of spending a Taproot output:

Through the key path: simply providing a BIP340 signature signing the spending transaction with the public key in the output.
Through the script path: revealing that the output was in fact a tweaked key, by revealing the original and the tweak, and showing that this tweak commits to a script leaf. This is where the control block comes into play.

When spending through the script path, the signer has to provide a number of pieces of data to let their spend be verified:

The revealed script.
The inputs needed to satisfy that script (signatures and whatever other data it may need).
The leaf version (for now, always 0xc0, as specified in BIP342).
The internal key (the public key before tweaking)
The Merkle path to prove that the tweak commits to the revealed script and leaf version (#1 and #2).
A sign bit to indicate whether the output key was negated or not (this is necessary to enable batch validation).

The tweak itself is not revealed. It is recomputed by the verifier from the revealed script, leaf version, and internal key. Then it is verified that tweaking the internal key with that tweak matches the public key in the output being spent.
This brings us to the question of how all this information is encoded in the spending input's witness stack:

First, all the inputs to the script being spent (#2 above)
As penultimate item, the revealed script (#1 above)
As final item, the control block, which contains all the other information:

Its first byte stores the leaf version (#3) (top 7 bits) and the sign bit (#6) (bottom bit).
The next 32 bytes store the (X coordinate only, because x-only key) of the internal public key (#4)
Every block of 32 bytes after that encodes a component of the Merkle path (#5) connecting the leaf to the root (and then, the tweak), going in bottom-up direction.

"Through the script path: revealing that the output was in fact a tweaked key" But every output is a tweaked key right? Even if you pay through the key path it was still a tweaked key. The way you've phrased it here it sounds like for key path spends it isn't a tweaked key (or may not be a tweaked key) https://bitcoin.stackexchange.com/questions/99325/i-want-to-create-a-p2tr-pay-to-taproot-address-but-i-just-need-a-key-path-spen

The BIP recommends always tweaking, even when there are no script paths. But there is obviously no way to enforce this, because it is not revealed whether or not that is the case for key path spends. It's perfectly possible to take a public key directly, turn it into an address, have someone pay to it, and then spend by signing that directly.

Interesting, thanks. So it is a question of whether wallets follow the BIP or ignore this detail in the BIP and take a shortcut here. I was thinking of the BIP as the "standard" that wallets would implement. But yeah I can see the shortcut being taken by some wallets here.

I don't expect any wallet to take that shortcut, but it doesn't change the fact that if you just see a key path spend, you technically cannot know if it was a tweaked key or not (and if it was, tweaked with what).

Just semantics then. If literally zero wallets take the shortcut then you know pretty much every Taproot public key is a tweaked key (whether they need the script path or not). You need some subset of wallets to take the shortcut for there to be uncertainty whether it is a tweaked key or not.

The control block is the data required to prove that a specific script is within the Taproot tree (script path).
Murch defines the control block here (replacing "inner key" with "internal key"):

When a fallback to the backup key is necessary, the existence of the Taproot tree must be revealed. If there is only a single leaf, the spender provides only the internal key. Tweaking the internal key with the hashed leaf results in the public key. In sum, the data necessary to prove the existence of a script path is called the control block.

BIP 341 adds additional details on the "control block":

The last stack element is called the control block c, and must have length 33 + 32m, for a value of m that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.

To prove D (the hash of a particular script) is in the Taproot tree, the control block would need to contain the following data in this order:
<control byte with leaf version and parity bit> <internal key p> <C> <E> <AB>

To prove D is in the Taproot tree you need to be able to hash up to the Merkle root (ABCDE) and to do that you need to hash C with D, then E with CD, and then AB with CDE.


text:
Is there any way to "revoke" a bitcoin address?
Given e.g. one lost the private key to a specific bitcoin address, is there any way to make sure no more bitcoins can be transferred to it since it effectively became a bitcoin-furnace?

Unfortunately, there is no way to do any such thing. Your only option is to manually inform any business partners that the address has fallen out of use.
As the only way to proof indubitably that you were the owner of said address would be to sign a message with the respective private key, I don't see how anyone could justifiably shut down an address.

sadly unlike PGP there is no separate revocation key, though one could sign the "I've lost the key" message in advance and put it someplace safe...

That's right. But then you could just as well put a backup of the private-key someplace safe. ;)

True - though you could give the signed revocation to someone else who would then still be able to refute any claim of theft, and you wouldn't need to trust them too much

Right, I hadn't thought about that.


text:
Are there any _severe_ drawbacks of bitcoin justifying all the alternatives?
There exist quite some alternatives to bitcoin that are partially based on it, and I'm sure their creators all are convinced they improve upon something. But are there any serious drawbacks in bitcoin that can or will probably never be fixed?

Related Why do we need alternatives to Bitcoin?

I don't think there are severe drawbacks of Bitcoin. Certainly none that other coins are solving.
However, Bitcoin has certain properties that could be replaced with some other. Most altcoins to just that. Popular properties that altcoins change are:

replace PoW with something else

Some altcoins do not use a PoW mechanism or use a hybrid mechanism. PeerCoin (originally named PPCoin) was the first altcoin to use the Proof-of-Stake mechanism, which basically requires miners to hold a certain amount of currency in order to mine new. PeerCoin uses a hybrid of PoS and PoW. Nxt is an altcoin that uses pure PoS.

the PoW algorithm

Bitcoin uses SHA-256, which is a hash algorithms that almost entirely requires CPU cycles to calculate. This means that it is easy to create custom hardware to perform this calculations. There are many altcoins that use Scrypt as the PoW algorithm. Scrypt is more memory-intensive and therefore harder to implement in custom hardware. The first altcoin to implement Scrypt is Litecoin. Primecoin requires miners to calculate large prime numbers as a PoW mechanism.

the total amount of coins that can be mined

Bitcoin has a 21 million coin limit. Some altcoins raise this limit, such as Dogecoin, others lower it, such as 42.

the rate at which new blocks are created

Bitcoin blocks are mined at an average rate of one block every 10 minutes. Many merchants require that a transaction has been confirmed by several blocks before they accept it. With a confirmation time of 10 minutes (in fact, the recommended amount of confirmations to wait for is 6) can be quite cumbersome in certain use cases. Litecoin has a confirmation time of 2.5 minutes.

the time it takes before the maximum amount of coins is created

Block rewards usually have a halving time. Every halving time the block reward halves until it is too low to represent using the maximum precision and it becomes zero. With Bitcoin it will take until 2140 until the block reward becomes zero. Some coins shorten this period. Sometimes they shorten it so much that the creator (who mines first, of course) is accused of pre-mining because he can mine very fast and easy in the beginning of the existence of the coin.

Thanks! PoS sounds interesting, and I like the idea of primecoin trying to calculate something actually (slightly) useful instead of brute-hashing. Personally, I consider changing the amount of total coins nonsense though, since that is equivalent to changing the scale (apart from, maybe, changing for how long miners get a reward in addition to fees).

Well, take care with PoS though. I once read a post from one of Bitcoin core devs (yeah I lost the post and can't find it anymore) that PoS is not at all as safe as PoW is. And about increasing the amount, the Dogecoin community quite enjoys talking in big numbers :) It sounds better that you can say I own 10k doge instead of 1 BTC, right?

Well, I could say I own a billion nano-Satoshi :P But PoS alone does indeed sound a bit risky - if one party does manage to hold the majority of altcoins they'd most likely increase their lead forever, and there seems to be no mechanism to prevent that. Though, I start having an idea - one could track which part of a given transaction was already "used" as PoS (via it's history) and only unused parts, to be included (in the respective fraction) in the coinbase transaction, would count

I think that's somehow the principle of how it works. But I thought the main issue was that there was much less incentive for minders to only work on the current branch. The way of gaining your PoS share is by being lucky to be picked and you will get your stake * the time you are holding it without PoS share. But because no "work" is involved, it would make sense to keep trying to append your self after any recent block to try having more luck there. It was something like that. Could result in regular forks and orphaned blocks.


text:
Can the Bitcoin network be used as a timestamping service?
Does the Bitcoin protocol provide means to add some freely definable data to transactions such that a small transaction could actually be used to timestamp arbitrary data?

Based on the links in spuder's rather brief answer and also taking care of a rare restriction:
As the Private key bitcoin wiki entry states,

any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key

Therefore, in order to have the bitcoin network timestamp a message, one can proceed like this:

Use a 256 bit hash, usually SHA-256, as a private key⁺ that one imports into one's bitcoin wallet
Transfers a small amount of bitcoins to the corresponding address and swiftly afterwards back to your own account. Since this is a fresh bitcoin address, you might have to pay a fee for this transfer unless you can afford to wait for some time
Once the transaction back to your own account has been confirmed, publish your message and one of the two transaction ids. Everyone can now easily verify that your message's hash yields a bitcoin address that was used at the time you claim to have published your message. Be aware that since anyone with access to your message can therefore simply reconstruct also the private key, so be sure to have no funds left there!

In fact, that caveat of having to wait until you transferred the funds back to an account the private key of which is secret can be easily circumvented: Instead of a simple transaction, transfer funds to a 2-of-2 multisignature transaction that needs to be signed both by the hash "private" key and one of your truly secret private keys. Now you can leave the funds on that transaction until you want to spend the bitcoins for another purpose without having to fear someone else can spend it. However, keep in mind that currently no client seems to have any intuitive way of creating or spending multisignature transactions!

⁺ In the very rare case that hash is outside the permitted range (less than 2¹²⁸ of the 2²⁵⁶ possible values), one additionally has to do something, e.g. wrapping into the valid range via
min_val = 1
max_val = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
priv_key = ((sha256(message) - min_val) % (max_val - min_val)) + min_val

Yes, the bitcoin network can be used as a timestamping service
Here is an article about it
https://www.strongcoin.com/en/blog/using_the_blockchain_as_a_trusted_timestamping_service
Here are additional instructions:
https://bitcointalk.org/index.php?topic=52715.0

Based on these links I provided a more elaborated answer

Yes, but you only get a few bytes(not sure exactly how much, i think around 30, not even near a kilobyte for sure) per transaction, so the best way to go about it would be to hash your data first and then use that instead.


text:
How to get correct address from BTC mnemonic phrase in Python
Faced a problem, I have a crypto wallet written in Python, there is a code that creates a wallet address from a mnemonic phrase (In this case, BTC address). But if I enter this mnemonic phrase into the Trust Wallet mobile app, it will give me a completely different Bitcoin address. Why? How to fix it? Here is the code:
from bipwallet import wallet
from bipwallet.utils import *

Seed = wallet.generate_mnemonic()

WalletBTC = wallet.create_wallet(network="BTC", seed=Seed, children=0)

AddressBTC = WalletBTC.get("address")

print("BTC Address: ", AddressBTC)

The derivation path must be the same too not just the mnemonic

I assume both the Python library and Trustwallet implement BIP32 to create hierarchical deterministic (HD) wallets.
The address you get depends on the derivation path. If your Python library and Trustwallet use different derivation paths, you will get different addresses.
An HD wallet will produce multiple addresses, a different one each time you request an address. So you must be careful not to compare the 1st address from one wallet with the 2nd address from another.

Thank you.
I independently found libraries that generate the same address as Trust Wallet, as well as Cryptoneed (Mobile Apps).
Who needs my code, copy and customize for yourself:
from hdwallet import BIP44HDWallet
from hdwallet.utils import generate_mnemonic
from hdwallet.derivations import BIP44Derivation
from hdwallet.cryptocurrencies import BitcoinMainnet, EthereumMainnet
from bip_utils import Bip84, Bip84Coins, Bip44Changes, Bip39SeedGenerator

LanguageInMnemonic = "english"

Mnemonic = generate_mnemonic(language = LanguageInMnemonic, strength = 128)
    Seed = Bip39SeedGenerator(Mnemonic).Generate()

    print(Mnemonic)

    if IsCheckBTC == "+":
        if IsCheckBTCBip44 == "+":
            CheckedWalletBTCBip44 = BIP44HDWallet(cryptocurrency=BitcoinMainnet)
            CheckedWalletBTCBip44.from_mnemonic(mnemonic = Mnemonic, language = LanguageInMnemonic, passphrase = None)
            CheckedWalletBTCBip44.clean_derivation()
            CheckedWalletBTCBip44Derivation = BIP44Derivation(cryptocurrency = BitcoinMainnet, account = 0, change = False, address = 0)
            CheckedWalletBTCBip44.from_path(path = CheckedWalletBTCBip44Derivation)

            CheckedAddressBTCBip44 = CheckedWalletBTCBip44.address()
            print(CheckedAddressBTCBip44)

        if IsCheckBTCBip84 == "+":
            CheckedWalletBTCBip84 = Bip84.FromSeed(Seed, Bip84Coins.BITCOIN)
            CheckedWalletBTCBip84Step1 = (CheckedWalletBTCBip84.Purpose().Coin().Account(0)).Change(Bip44Changes.CHAIN_EXT)
            CheckedWalletBTCBip84Step2 = CheckedWalletBTCBip84Step1.AddressIndex(0)

            CheckedAddressBTCBip84 = CheckedWalletBTCBip84Step2.PublicKey().ToAddress()
            print(CheckedAddressBTCBip84)

    if IsCheckETH == "+":
        CheckedWalletETH = BIP44HDWallet(cryptocurrency = EthereumMainnet)
        CheckedWalletETH.from_mnemonic(mnemonic = Mnemonic, language = LanguageInMnemonic, passphrase = None)
        CheckedWalletETH.clean_derivation()
        CheckedWalletETHDerivation: BIP44Derivation = BIP44Derivation(cryptocurrency = EthereumMainnet, account = 0, change = False, address = 0)
        CheckedWalletETH.from_path(path=CheckedWalletETHDerivation)

        CheckedAddressETH = CheckedWalletETH.address()
        print(CheckedAddressETH)

(P. S. I used google translate)

Why is the definition of IsCheckBTC not defined in your code snippet???

Please you i get a php version of this code instead of Python.
I have a seed Phrase. I want the BTC address that correspond with Blockchain.
I want code in PHP so that i can modify to suit my project


text:
Can a hacked/tampered full node be deployed in Bitcoin to accept blocks containing invalid transactions?
What if I deployed 3 of my personal tampered/hacked full nodes(with one of them a miner too) that accepts invalid blocks with proper PoW (containing invalid transactions) and rejects valid blocks. Assume there were previously 2 neutral full nodes in the blockchain with one of them a miner. Whose copy of the blockchain will be the true one now in such a case where we have majority of tampered full nodes accepting invalid blocks.
Also is this what's called a sybil attack in a blockchain?

The other two nodes would attempt to validate the invalid block, find it to contain invalid transactions, and thus those nodes will discard and ignore it.
Those two nodes will continue to follow the longest chain that is valid according to the rules they enforce. There could be one million other nodes that all follow the invalid block, but that would be without consequence to the two ('honest') network peers.

Whose copy of the blockchain will be the true one now in such a case where we have majority of tampered full nodes accepting invalid blocks

If they continue to follow the invalid chain, then the malicious nodes would create a new network, due to an incompatible (hard forking) rule change. The original network would continue to operate, otherwise unaffected by this.

is this called a Sybil attack or a 51% attack? (my guess is it cannot be called a 51% attack because we don't have the majority hash rate but only influence majority of full nodes)

@ManavKampani A majority attack (51% attack) involves controlling a majority of the hashrate. What you've described isn't really a sybil attack either, as the dishonest nodes will just be ignored/banned by other nodes if they continuously misbehave. What you're imagining is perhaps most similar to an eclipse attack (which can overcome by making a connection to only one single honest peer).

so basically even if there's a single working neutral node in the network (assuming it's also a miner node) the blockchain will work just fine and secure.

@ManavKampani well, if there were zero honest nodes, then there wouldn't really be a network to speak of in the first place. No number of dishonest nodes (or miners) can convince an honest node to accept an invalid block. For eclipse attacks, see: https://bitcoin.stackexchange.com/questions/tagged/eclipse-attack?tab=Votes

okay but I'm asking about a single honest full miner node, will the network work then?

@ManavKampani if there were no miners on the network, then the network would not progress (no new blocks being added). If there were only one miner, the network could progress, but users of that network would likely have censorship (majority attack) concerns. Having many competing miners on the network alleviates this concern.