Excuse my ignorance also, but how does the SX implementation of stealth addresses work, if it cannot work with Core client when limited to 40 bytes of arbitrary data in a transaction? Using these tricks that embed data in the transaction signature? As I understand it the secret exchange has to happen out-of-band now instead of happening in the blockchain itself. It doesn't kill the feature, but does make it less usable. As I understand the sender can use the public key in one of the inputs to encrypt the nonce. So everything will be on the blockchain permanently, without occupying more space than a normal transaction |
|
|
|
Virtually no change: 16 BTC sold, most likely rounding error (Friday April 25th).
Thank you. Please also quote the raw data (NAV and total asset) since I may occasionally forget to take the values |
|
|
|
再一次向各位強調, 如果你用的是bitcoin-qt / bitcoin core, 你需要每進行100次交易 (包括收款/付款) 最少備份錢包一次, 否則可以有嚴重後果
这是BC的提醒，没错。但我现在仅有可怜的几笔交易。 最好的方法是不要用bitcoin-qt/bitcoin core 作為錢包, 改為用Armory
我认为BC钱包还是最好。有人发帖说过Armory的问题，让他丢币了。原因是那个人的交易量太大。具体的细节我不太记得了。 以Armory的設計交易量多大也不可能丟幣, 沒看到細節我不相信真的有人丢幣 (丢幣的唯一定義是失去了private key) |
|
|
|
edit: can someone explain how is it possible to find a public adress like bitcoineaterdontsend? It seems to me that this is the highest degree in the art of destroying bitcoins, so I want to explain how to do it (theoretically).
I have answered this question many times, in many different ways. Address is just a special way to present an integer. There is no magic in it at all. 1111111111111111111114oLvT2 = 0000000000000000000000000000000000000000 1BitcoinEaterAddressDontSen df59kuE = 759d6677091e973b9e9d99f19c68fbf43e3f0 5f9I "generated" the following one in 10 seconds which has never been used: 1BitcoinEaterAddressDontSen ts7VUGT = 759d6677091e973b9e9d99f19c68fbf43e3f0 680If you just want to generate an address like 1BitcoinEaterAddressDontSendf59kuE, you don't need ECDSA. ECDSA will not give you an address like 1BitcoinEaterAddressDontSendf59kuE before the death of our sun. thank you. And how do you know "759d6677091e973b9e9d99f19c68fbf43e3f0" is bitcoineaterdontsen ? If I wanted to created an adress 1BergmannsBitcoinGraveXYZ999ABC1 -- how could I do that? It's just base-58 encoding plus a checksum https://en.bitcoin.it/wiki/Base58Check_encoding1BergmannsBitcoinGraveXYZ999ABC1 is not a valid address because the checksum is not correct You need to first convert your base-58 string to hexadecimal, calculate the checksum, and convert it back base-58. Read https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addressesThe calculation is tedious but a high school student should be able to do it. |
|
|
|
edit: can someone explain how is it possible to find a public adress like bitcoineaterdontsend? It seems to me that this is the highest degree in the art of destroying bitcoins, so I want to explain how to do it (theoretically).
I have answered this question many times, in many different ways. Address is just a special way to present an integer. There is no magic in it at all. 1111111111111111111114oLvT2 = 0000000000000000000000000000000000000000 1BitcoinEaterAddressDontSen df59kuE = 759d6677091e973b9e9d99f19c68fbf43e3f0 5f9I "generated" the following one in 10 seconds which has never been used: 1BitcoinEaterAddressDontSen ts7VUGT = 759d6677091e973b9e9d99f19c68fbf43e3f0 680If you just want to generate an address like 1BitcoinEaterAddressDontSendf59kuE, you don't need ECDSA. ECDSA will not give you an address like 1BitcoinEaterAddressDontSendf59kuE before the death of our sun. |
|
|
|
So - some easy step-by-step guide to find a public adress without the priv key?
1. buy a hexadecimal dice  2. throw 40 times 3. for example the result is 0123456789abcdef0123456789abcdef00000000, get the address from https://blockchain.info/address/0123456789abcdef0123456789abcdef000000004. the address is 171vsZ3PsK9vcyajd3FW1m2AfLzs68Z8o "How to destroy Bitcoins"
The easiest way is send your bitcoin to 1111111111111111111114oLvT2 or 1BitcoinEaterAddressDontSendf59kuE |
|
|
|
thanks
Is it possible to create a valid adress without the private key?
Yes, but it's practically impossible to find the private key for it. See - 1BitcoinEaterAddressDontSendf59kuESorry, I don't understand the mathematics. The BitcoineaterAdress - how was it created? Did someone created addresses to bruteforce the bitcoineater-public-adress? Ok, let me do it again 1. "Bitcoin address" is just a human readable expression of a number.For example, my donation address 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion is equivalent to the hexadecimal number 80857aaa19a17c0ef98fe525316ce131492a5c40; 1BitcoinEaterAddressDontSendf59kuE is equivalent to 759d6677091e973b9e9d99f19c68fbf43e3f05f9; 1111111111111111111114oLvT2 is equivalent to 0000000000000000000000000000000000000000 2. All integers from 0 to 2^160-1 are valid bitcoin addressesSo 0000000000000000000000000000000000000000 = 0 is a valid bitcoin address. Do you need a private key to generate a "0"? Obviously no. |
|
|
|
thanks
Is it possible to create a valid adress without the private key?
Please read carefully: all integers from 0 to 2^160-1 are valid bitcoin addresses. |
|
|
|
Something I don't understand:
If I create I a brainwallet, I receive a public adress. Do I write the adress with this act into the blockchain (how??), or was the public adress there, before I created the brainwallet? Is every public adress availible to receive bitcoins, cause there's a limitation in possible public adresses, which can be calculated with the private key, so that it's impossible to type a valid public adress by randomly tipping?
(and do miner something like finding randomly public adresses?)
Simply speaking, all integers from 0 to 2^160-1 are valid bitcoin addresses. You can send bitcoin to any of these addresses. Miners don't know and don't care whether there is a corresponding private key for such address, until someone tries to spend. (Read more at https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses . For example, my donation address 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion is equivalent to the hexadecimal number 80857aaa19a17c0ef98fe525316ce131492a5c40) |
|
|
|
央行在约谈中强调，提现功能也必须停止。
IMHO, it's really stupid to comment based on google translation. The correct translation of the last sentence should be: "fiat withdrawal must also be stopped". Thanks! But this is bad news anyway, isn't it? What do they mean by "cash withdrawal"? 提现 literally means "withdraw cash", but in this context it means "fiat withdrawal through a bank/payment processor". |
|
|
|
They also gave us the solution: cash.
The new PBoC "clarification of the clarification" mentions cash too. But I cannot figure out exactly what they mean. As of April 24 , all Bitcoin trading platform has been fully recharge way to stop third-party payment . Most bank card remittance channels have been closed , however , are still allowed to bitcoin bank transfer and cash withdrawal services platform .
In the interviews emphasized the central bank , cash function must also be stopped.
截至4月24日，各比特币交易平台已全面停止第三方支付充值方式。银行卡转账汇款渠道大多数已经关闭，然而，仍有银行允许给比特币平台汇款和提现服务。
央行在约谈中强调，提现功能也必须停止。
IMHO, it's really stupid to comment based on google translation. The correct translation of the last sentence should be: "fiat withdrawal must also be stopped". |
|
|
|
So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear. Wow, the antispam fees are actually working for once, in a sense! Your service is exactly what the fee aims to prevent. Bitcoin's blockchain is not a micropayment system. Bitcoin could be a better system for micropayment, if it allows: 1. shorter public keys and key hash: you don't need the full protection just for just 100 satoshi. Something that is bruteforcable in a few months is already more than enough 2. signing multiple inputs with one signature 3. adopt a balance based system There are a number of ways Bitcoin could be extended to do micropayments; I was just commenting on the OP's present use. (btw, your suggestion #3 is fatally flawed when it comes to avoiding double spends...) I think I have found a solution: https://bitcointalk.org/index.php?topic=552624.msg6376604#msg6376604Please see if you could find further flaws |
|
|
|
Any other solution?
Not ones that aren't probabilistic, or don't require the sender to keep track of all the nonsense. Hmm, this seems to be the biggest issue with it. Would be nice to find a nice solution. I think I have a solution: to have a output-based and balance-based mixed system There are 2 types of addresses, output-based address and balance-based address. Bitcoin sent to an output-based address will be spent like the current system (i.e. identified by txid and index), while for a balance-based address it will be spent like the system proposed in OP. There is no restriction in the redemption of output-based bitcoin. However, balance-based bitcoin must be spent with an output-based bitcoin, using SIGHASH_ALL. Therefore, the signature is not replayable because the output-based bitcoin is already spent. |
|
|
|
So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear. Wow, the antispam fees are actually working for once, in a sense! Your service is exactly what the fee aims to prevent. Bitcoin's blockchain is not a micropayment system. Bitcoin could be a better system for micropayment, if it allows: 1. shorter public keys and key hash: you don't need the full protection just for 100 satoshi. Something that is bruteforcable in a few months is already more than enough 2. signing multiple inputs with one signature 3. adopt a balance based system |
|
|
|
I'm thinking about a system where nodes can look at old transactions, ordered chronologically.
Oldest transactions should be forced in, not left up to miner's discretion. That's the basic idea.
What do you guys think?
Thanks all for the responses.
Yes Danny, I'm generally aware of these kinds of issues that exist in a distributed system.
We have to create consensus among the nodes.
I haven't created an implementation plan yet...still gathering information to fully understand the problem.
Let me think about the "how" this can be done.
Bitcoin is ALREADY a consensus system for the chronology of transactions. So you are just going to reinvent bitcoin, or something that is fundamentally better than bitcoin. |
|
|
|
what transactions does the protocol try to force to be included in a block?
Nope
what transactions does the protocol try to force to be excluded in a block?
Any invalid transactions |
|
|
|
因为BTC地址是在生成钱包的时候已经全部生成了，只不过没有被唤出来而已。[/size]
不是"全部", 預設只有100個 是的，我没有表述清楚。谢谢 再一次向各位強調, 如果你用的是bitcoin-qt / bitcoin core, 你需要每進行100次交易 (包括收款/付款) 最少備份錢包一次, 否則可以有嚴重後果 最好的方法是不要用bitcoin-qt/bitcoin core 作為錢包, 改為用Armory |
|
|
|
Any update for the last six days? I'm really curious  Updated. Around 200XBT bought since last update I stop update usually because nothing interesting happened |
|
|
|
因为BTC地址是在生成钱包的时候已经全部生成了，只不过没有被唤出来而已。[/size]
不是"全部", 預設只有100個 |
|
|
|
|
Show Posts
