Search content
Sort by
Showing 20 of 2,768 results by phelix
Re: action=.xml is disabled due to slowness. If you use this, write a post in Meta
Alright, I'll try to enable at least some of its functionality in the near future. (The trouble is that action=.xml has a whole bunch of options, and I know that some combinations of options end up resulting in minutes of computation. I need to figure it out.)
Note that I only sample that page every 10 minutes with exactly these options:https://bitcointalk.org/index.php?action=.xml;sa=recent;limit=255
If there is another way to achieve something similar (a largish number of recent posts) I might look into it as well.
Re: action=.xml is disabled due to slowness. If you use this, write a post in Meta
> action=.xml is disabled due to slowness. If you use this, write a post in Meta explaining your usage.
I use it for my website http://blockchained.com bitcointalk top posts. Without xml parsing it won't work.
edit: the page I need to access is: https://bitcointalk.org/index.php?action=.xml;sa=recent;limit=255
I use it for my website http://blockchained.com bitcointalk top posts. Without xml parsing it won't work.
edit: the page I need to access is: https://bitcointalk.org/index.php?action=.xml;sa=recent;limit=255
Re: Bitcoin 100 has run its course. This is the rebate thread.
Thank you very much for your work Bruno. Also thanks to Rassah and whoever else donated time to make this work.
BTC address sent by PM (for what it's worth).
Greetings to all donators, that were good times!
BTC address sent by PM (for what it's worth).
Greetings to all donators, that were good times!
Re: [announce] Namecoin - a distributed naming system based on Bitcoin
The point here is to validate ownership of names, not restrict the total number of names or in the system to an arbitrary upper limit, right?
If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks? That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated? POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.
The way it is implemented there is the currency in between.If so, would it be possible to tie in the difficulty of the proof-of-work to be based on the number of new name requests seen in the past two weeks? That is, the more requests, the easier the difficulty of hashing a block, and the more quickly blocks are generated? POW would also obviously have to be tied into the amount of processing power being thrown at the network as well.
btw: Help needed testing this Namecoin id/ pgp keyserver: https://forum.namecoin.info/viewtopic.php?f=9&t=2476
btw2: The rebased client is humming along nicely. There is an external rpc GUI frontend for name operations with the new client available (nameGUI, includes experimental secure name trading). Even the manage name tabs might come back to the new client.
btw3: There is a roadmap now (work in progress) that shows some of things that are currently going on: https://github.com/namecoin/meta/blob/master/roadmap.md
BIP9 might break current merged mining... https://forum.namecoin.info/viewtopic.php?p=16150#p16150
In this case, where they know the previous block is valid b/c they mined it, why wouldn't they simply mine the next with tx's in it? the reason these spv miners do what they do is b/c they don't want to waste time validating another pools just received block, which is not the case in this situation since it's their own.
It is both as can be seen when 2 blocks back to back come from an SPV pool and the 2nd block has zero txns. The reason is they've not gone to the effort to make the bitcoind validation process fast in their own nodes and they don't want to wait for bitcoind to validate the block (it takes time) before starting on their next block. For solo.ckpool.org and kano.is we run a customised bitcoind which speeds up the validation process dramatically, making this delay negligible.Nice summary by Chris Pacia in this blog post:
https://chrispacia.wordpress.com/2015/11/29/on-zero-confirmation-transactions/
Quote
retailers will be able to detect unconfirmed RBF transactions and reject them
But there is no need to "reject", you just don't process these transactions until you have some confirmations. Users that "opt-in" on RBF might have to wait longer in some situations.I still wonder how this is supposed to be handled on the sender user interface - it seems very difficult to explain the implications to a normal user ("click here so your transaction is less likely to get stuck in the network but more likely to be delayed on the recipient side"?)
FSS-RBF certainly is a better solution from a user perspective even if it is less elegant protocol wise. Maybe it will also be added at some point. Or the awesome "Delayed-RBF" solution in the OP
edit: btw is it only me that considers the use case for RBF of "Paying multiple recipients in succession" pretty irrelevant? Currently this is simply done by batching transactions so the practical cost savings will be minimal.
⭐ Merited by ABCbits (1)
The latest attempt to add RBF to Bitcoin Core might cause unexpected delays in user experience by vendors waiting for (sender controlled opt-in) RBF. Would it be possible to modify RBF so that the transaction replacement is delayed? E.g. disregard replacement tx if the original tx has been in the mempool for less than six blocks. This way zero conf tx should not be affected, still stuck transactions could be fixed after some waiting time.
background: https://www.reddit.com/r/Bitcoin/comments/3ul1kb/peter_todds_rbf_replacebyfee_goes_against_one_of/
background: https://www.reddit.com/r/Bitcoin/comments/3ul1kb/peter_todds_rbf_replacebyfee_goes_against_one_of/
Re: Is it secure to use bitcoin private public key for message encryption?
Earlier discussion here: https://bitcointalk.org/index.php?topic=128230.msg1621711#msg1621711 and https://bitmessage.org/forum/index.php?topic=4170.0
It all boils down to: Using the same key for signing and encryption seems to work in theory but might cause security issues in practical use. At the very least it is even more difficult to get right so better avoid it.
It all boils down to: Using the same key for signing and encryption seems to work in theory but might cause security issues in practical use. At the very least it is even more difficult to get right so better avoid it.
if at all true, then it has to be one of these addresses:
http://ondn.net:800/
so any bitcoin analysts care to investigate?
hehe, this is a good idea. I'd say at the time of posting (2015-09-20) the Bitcoin price was around $231: http://bitcoincharts.com/charts/bitstampUSD#rg90zczsg2015-09-19zeg2015-09-21ztgSza1gEMAzm1g10za2gEMAzm2g25zvhttp://ondn.net:800/
so any bitcoin analysts care to investigate?
This makes BTC 12987
Top100 balances from 2015-09-20 anybody?
The bounty fund will pay out [...] for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Would this suite Joinmarket? https://bitcointalk.org/index.php?topic=919116
Was the work proposed in this thread?
In order to further incentivize work in this space there is now a multisignature escrow bounty fund:
3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk
(yes, Bitcoin addresses can also start with a 3)
This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.
The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Please feel free to contribute to the above address to support work on this infrastructure.
Multisig address construction details:
Would this suite Joinmarket? https://bitcointalk.org/index.php?topic=9191163M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk
(yes, Bitcoin addresses can also start with a 3)
This is a two-of-three multisignature escrow with myself, Theymos, and Pieter Wuille as signers. To release any coin sent to this address at least two of these people must sign the transaction.
The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Please feel free to contribute to the above address to support work on this infrastructure.
Multisig address construction details:
Code:
Key from Theymos:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b
-----BEGIN PGP SIGNATURE-----
iF4EAREIAAYFAlISs5MACgkQxlVWk9q1kednkgD/WvE3F1hSoKHIr+y7q3O6xbGp
FM+P/lVbi/nZugrlNKABALMhYih2Ov80OS1PLMX9UpONn2eE2Xu+ZkxZ2SkQFfCU
=lFI0
-----END PGP SIGNATURE-----
Key from Gmaxwell:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a public key of mine, usable for the CoinJoin bounty fund:
027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlIbCV4ACgkQrIWTYrBBO/ooAgCdG9twTEFH5q+5Pip9qDOGsoww
a7YAoLfVP4CBaxk5mnpMXVHpQXqgVwxL
=k1JR
-----END PGP SIGNATURE-----
Key from Pieter:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGcBAEBCAAGBQJSpLf6AAoJEI9lMlXIeZLgtRkL/3ufWgLyhTKM9T30JqA0a/Xh
5KUMD0csuxTMYraVOy9x7tRVZh+fETt4Y3clhErZj8g6VraC5ku+4pyHxtFztWor
N6QadkAvwuCAqmBxbAmb7hTq41eXjptzwqyUWh/z6YecBKeRIxIi/8LGqX/+gODd
GlKj66Ex27wgp9gJp/1Ot+hrTmmasxXAEjXYJTKr4LjJeajH/HJJQeCI6jTy4fdm
TsplX7rUgzhdZQ60malyn1MCmtdXRviWyWuAvKgpIaEMaZsFCSMfvNzUtKHiMv3n
HPxe9OAv1V2rdwU9oa7gxHLSvF7BER1XpWcA0UKTeD1w2/vzPZj3exDDHT8A35Ro
nhK6cJPYTdnzXLavpFqRD85R1G9W3rl4IzqfflXwWB2rRByyLROvrMfVG8iLMYP0
JcaB+8kttzqTa0vBiaosCvSbFZAfw2seyXxxF5anH4Q0ueMJKglLp6rE/51s1bQa
Hz6rsSAAdvx/OSCitKp1+JMzSKA/SwNMRUy4VqKQ4g==
=70Dh
-----END PGP SIGNATURE-----
2-of-3 Address construction:
$ bitcoind createmultisig 2 '["02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b","027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1","0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592"]'
{
"address" : "3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk",
"redeemScript" : "522102d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b21027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1210292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa673259253ae"
}
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b
-----BEGIN PGP SIGNATURE-----
iF4EAREIAAYFAlISs5MACgkQxlVWk9q1kednkgD/WvE3F1hSoKHIr+y7q3O6xbGp
FM+P/lVbi/nZugrlNKABALMhYih2Ov80OS1PLMX9UpONn2eE2Xu+ZkxZ2SkQFfCU
=lFI0
-----END PGP SIGNATURE-----
Key from Gmaxwell:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a public key of mine, usable for the CoinJoin bounty fund:
027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAlIbCV4ACgkQrIWTYrBBO/ooAgCdG9twTEFH5q+5Pip9qDOGsoww
a7YAoLfVP4CBaxk5mnpMXVHpQXqgVwxL
=k1JR
-----END PGP SIGNATURE-----
Key from Pieter:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Here is a public key of mine, usable for the CoinJoin bounty fund:
0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGcBAEBCAAGBQJSpLf6AAoJEI9lMlXIeZLgtRkL/3ufWgLyhTKM9T30JqA0a/Xh
5KUMD0csuxTMYraVOy9x7tRVZh+fETt4Y3clhErZj8g6VraC5ku+4pyHxtFztWor
N6QadkAvwuCAqmBxbAmb7hTq41eXjptzwqyUWh/z6YecBKeRIxIi/8LGqX/+gODd
GlKj66Ex27wgp9gJp/1Ot+hrTmmasxXAEjXYJTKr4LjJeajH/HJJQeCI6jTy4fdm
TsplX7rUgzhdZQ60malyn1MCmtdXRviWyWuAvKgpIaEMaZsFCSMfvNzUtKHiMv3n
HPxe9OAv1V2rdwU9oa7gxHLSvF7BER1XpWcA0UKTeD1w2/vzPZj3exDDHT8A35Ro
nhK6cJPYTdnzXLavpFqRD85R1G9W3rl4IzqfflXwWB2rRByyLROvrMfVG8iLMYP0
JcaB+8kttzqTa0vBiaosCvSbFZAfw2seyXxxF5anH4Q0ueMJKglLp6rE/51s1bQa
Hz6rsSAAdvx/OSCitKp1+JMzSKA/SwNMRUy4VqKQ4g==
=70Dh
-----END PGP SIGNATURE-----
2-of-3 Address construction:
$ bitcoind createmultisig 2 '["02d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b","027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1","0292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa6732592"]'
{
"address" : "3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk",
"redeemScript" : "522102d5f2b9c68b22006161dfe58a78b37dc2b577e8bb4e4522940830264eb3b3a38b21027b48575c15712867a8a1e6c9f52f510946130bbdf3b1e2feb344b8b68232ffb1210292782efcb08d621c360d055f407c8e75ffbbd06f6b7009c1432ca9eaa673259253ae"
}
Idea: Joinmarket Autonomous Agent
A Joinmarket program living on a server making money all by itself via serving customers. Once it has made enough profit it can replicate by renting another server at a (pre programmed) hosting company and installing a copy of itself. It might even send some share home.
Given the somewhat critical nature of joinmarket/coinjoin regarding money laundering this might be a good match. Please consider whether this is legal first, I have no idea.
A Joinmarket program living on a server making money all by itself via serving customers. Once it has made enough profit it can replicate by renting another server at a (pre programmed) hosting company and installing a copy of itself. It might even send some share home.
Given the somewhat critical nature of joinmarket/coinjoin regarding money laundering this might be a good match. Please consider whether this is legal first, I have no idea.
Re: [announce] Namecoin - a distributed naming system based on Bitcoin
I like this project . One of the few altcoins that make sense and are useful. Sad to see onename and other projects move away from namecoin.
Here is our answer to that: http://blog.namecoin.org/post/130158040415/onenames-blockstore-is-much-less-secure-thanAnd here the ongoing discussion on reddit: https://www.reddit.com/r/Bitcoin/comments/3mwtw8/onenames_blockstore_is_much_less_secure_than/
Quote
Just curious , has the bitcoin core pruning feature -prune been ported to namecoin ? This allow to run nodes with minimal hard disk requirement
We are now stay in sync with Bitcoin. I don't know if anybody has yet tried pruning. With the Namecoin blockchain still being way smaller it is a lower priority and we rather want to go towards SPV.Re: [announce] Namecoin - a distributed naming system based on Bitcoin
With Onename switching to Bitcoin, will Namecoin be used at all for OpenBazaar?
Not that I know of. Onename and OpenBazaar both belong to the same VC company. Onename never answered my question about their business model so it smells like they will monetize lookups to their server (for "decentralized" data).Re: [announce] Namecoin - a distributed naming system based on Bitcoin
Is there a Namecoin slack channel?
No but there is #namecoin-dev on freenode and http://gitter.im/namecoin/lounge (bridged)Re: [announce] Namecoin - a distributed naming system based on Bitcoin
Namecoin is not dead. It just did what other scamcoins won't, and moved it's conversation to its own forum.
https://forum.namecoin.info/
Exactly.https://forum.namecoin.info/
Everybody thinking Namecoin is inactive please just take a look here: http://zmoazeni.github.io/gitspective/#/timeline/namecoin